3 ms·

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

by pandemic_region 2y ago

pests 2y ago
It feels weird to me that functions exist without being in the source code.
- pandemic_region 2y ago
  I never looked at it that way, but I get now where you're coming from. To me, the Lombok annotations are more like @Transactional, providing some useful boilerplate that I don't need to care about, it just works.
  - pests 2y ago
    I agree its extremely useful. I am just used to languages/frameworks that at least autogenerate the code. Maybe some inheritance to give you a place to make changes that wont be wiped.
dingi 2y ago
It’s not an innocent preprocessor. It’s a hack which breaks on almost every JDK upgrade.
- mschuster91 2y ago
  Now, given that a looot of projects use Lombok, it might be worth a try to actually standardize (or at least upstream) the feature given there seems to be an obvious demand of people to not having to pollute their codebase with tons of pointless getter and setter boilerplate.
  - cogman10 2y ago
    AutoValue, Immutables, MapStruct. All libraries that do what Lombok does without using JVM internals. Records also literally do a huge portion of what Lombok does. There are a lot of fairly popular alternatives to Lombok out there that don't need a constant eye on maintenance. Lombok is probably the most popular but that's really mostly because it's got the first mover advantage.
  - samus 2y ago
    Nobody requires projects to pollute their codebases with getter and setter boilerplate. People do that to themselves. The OpenJDK project should not enable that nonsense further, but provide support for better programming patterns. Support for creating getters and setters is already provided by annotation processors. Official support for compiler plugins (Lombok is an unofficial compiler plugin, not a mere annotation processor!) would effectively allow people to create dialects of Java. This would splinter and blunt the momentum that has carried the language forward for the last 30 years by fragmenting the ecosystem because for many legacy applications it will be impossible to migrate to one of the prevalent dialects.
JanecekPetr 2y ago
- It doesn't work with ErrorProne (https://github.com/google/error-prone/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20lombok https://github.com/google/error-prone/issues?q=sort%3Aupdate...) - you need a special plugin in your IDE for the generated classes to be visible and/or the code to be parsable - it does not work with many other tools, usually there is a bridge to fix that, e.g. with MapStruct: https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with-Project-Lombok https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with... Other tools and libraries generally do not interact in such an errorprone manner. That said, when you know how it works, what it needs, and you know how to iron all of those tiny wrinkles, it works fine and saves you some code and/or sanity. It's not the devil, it's a powerful tool with some downsides.
- pandemic_region 2y ago
  I did not know about ErrorProne thanks, I can see this is useful indeed and then Lombok would be the odd one out breaking that tool. About the special IDE plugin, IntelliJ has native support but yeah it needs a bit of attention that's true. Overall the minor extra hassle is still worth it in my world. We're not using all of the annotations, but (in order of utility) @AllArgsConstructor, @Data, @Getter, @Setter and the occasional @Synchronized.
dwattttt 2y ago
http://thecodelesscode.com/case/97 http://thecodelesscode.com/case/97 There's one of these for just about every occasion
gf000 2y ago
The biggest gripe is that it is not a preprocessor. Java has standard interfaces to properly preprocess code, and they have a very thoughtful limitation of no code modification, it is strictly additive. There are very cool libraries making use of it, e.g. mapstruct. Now, lombok in its current approach can't make use of it, as it explicitly wants to modify the given class with its annotations. This is forbidden, so they literally hack into the java compiler classes themselves, modifying the AST in-flight. As you can imagine, this might break at a new Java update any time.
- cogman10 2y ago
  > As you can imagine, this might break at a new Java update any time. It's not a might. If you look at the lombok changelog they have a release for nearly every new jdk version because they break constantly. When a project can't move up jvm versions it's very frequently been because of lombok. And if you look at the commit log, it's all a single dev running the show. He's been doing it for years which means the stability of your project is pretty dependant on this one guy keeping things up to date and finding work arounds to get at the jvm internals.

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

pests 2y ago

It feels weird to me that functions exist without being in the source code.

pandemic_region 2y ago
I never looked at it that way, but I get now where you're coming from. To me, the Lombok annotations are more like @Transactional, providing some useful boilerplate that I don't need to care about, it just works.
- pests 2y ago
  I agree its extremely useful. I am just used to languages/frameworks that at least autogenerate the code. Maybe some inheritance to give you a place to make changes that wont be wiped.

dingi 2y ago

It’s not an innocent preprocessor. It’s a hack which breaks on almost every JDK upgrade.

mschuster91 2y ago
Now, given that a looot of projects use Lombok, it might be worth a try to actually standardize (or at least upstream) the feature given there seems to be an obvious demand of people to not having to pollute their codebase with tons of pointless getter and setter boilerplate.
- cogman10 2y ago
  AutoValue, Immutables, MapStruct. All libraries that do what Lombok does without using JVM internals. Records also literally do a huge portion of what Lombok does. There are a lot of fairly popular alternatives to Lombok out there that don't need a constant eye on maintenance. Lombok is probably the most popular but that's really mostly because it's got the first mover advantage.
- samus 2y ago
  Nobody requires projects to pollute their codebases with getter and setter boilerplate. People do that to themselves. The OpenJDK project should not enable that nonsense further, but provide support for better programming patterns. Support for creating getters and setters is already provided by annotation processors. Official support for compiler plugins (Lombok is an unofficial compiler plugin, not a mere annotation processor!) would effectively allow people to create dialects of Java. This would splinter and blunt the momentum that has carried the language forward for the last 30 years by fragmenting the ecosystem because for many legacy applications it will be impossible to migrate to one of the prevalent dialects.

JanecekPetr 2y ago

- It doesn't work with ErrorProne (https://github.com/google/error-prone/issues?q=sort%3Aupdated-desc%20is%3Aissue%20is%3Aopen%20lombok https://github.com/google/error-prone/issues?q=sort%3Aupdate...) - you need a special plugin in your IDE for the generated classes to be visible and/or the code to be parsable - it does not work with many other tools, usually there is a bridge to fix that, e.g. with MapStruct: https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with-Project-Lombok https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with... Other tools and libraries generally do not interact in such an errorprone manner. That said, when you know how it works, what it needs, and you know how to iron all of those tiny wrinkles, it works fine and saves you some code and/or sanity. It's not the devil, it's a powerful tool with some downsides.

pandemic_region 2y ago
I did not know about ErrorProne thanks, I can see this is useful indeed and then Lombok would be the odd one out breaking that tool. About the special IDE plugin, IntelliJ has native support but yeah it needs a bit of attention that's true. Overall the minor extra hassle is still worth it in my world. We're not using all of the annotations, but (in order of utility) @AllArgsConstructor, @Data, @Getter, @Setter and the occasional @Synchronized.

dwattttt 2y ago

http://thecodelesscode.com/case/97 http://thecodelesscode.com/case/97 There's one of these for just about every occasion

gf000 2y ago

The biggest gripe is that it is not a preprocessor. Java has standard interfaces to properly preprocess code, and they have a very thoughtful limitation of no code modification, it is strictly additive. There are very cool libraries making use of it, e.g. mapstruct. Now, lombok in its current approach can't make use of it, as it explicitly wants to modify the given class with its annotations. This is forbidden, so they literally hack into the java compiler classes themselves, modifying the AST in-flight. As you can imagine, this might break at a new Java update any time.

cogman10 2y ago
> As you can imagine, this might break at a new Java update any time. It's not a might. If you look at the lombok changelog they have a release for nearly every new jdk version because they break constantly. When a project can't move up jvm versions it's very frequently been because of lombok. And if you look at the commit log, it's all a single dev running the show. He's been doing it for years which means the stability of your project is pretty dependant on this one guy keeping things up to date and finding work arounds to get at the jvm internals.