4 ms·

I can attest to how easy it's become to update jdks for our org. 8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious. 1

I can attest to how easy it's become to update jdks for our org. 8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious. 17->21 has been painless. And I have some projects running on 24 already with no problems. The feature delivery has been great and we are getting pretty close to not needing to do anything but update the jdk to move forward. Now, if only I could get devs to stop using lombok....

sgammon 2y ago
> Now, if only I could get devs to stop using lombok One of the only remaining reasons I discard libraries without a further thought
pandemic_region 2y ago
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.
pests 2y ago
Been a long time since I used Java. I checked out lombok since you mentioned it. Does it really just internally create all those methods without there being actual source code? It seems nice but really spooky-action-at-a-distance feeling. Sounds like a nightmare.
- DevelopingElk 2y ago
  Yes, from a language design it's ugly and the implementation is convoluted. From a user perspective it's awesome and enables better interfaces.
  - pests 2y ago
    I don't even agree with their demo video. It shows the "hard" way of autogenerating settings/getters, toString, hash, etc. The end result was like an additional ~80 boilerplate lines. I have no problem keeping those lines around.. opposed to adding the lombak.jar and changing my build config. I do understand the user perspective of it "just working" and of course the getters/setters will grow as you add fields... it just seems like such a low amount of code to keep around it shouldnt be too much hassle.
    - vbezhenar 2y ago
      It's not 80 lines. It's many thousands of lines in any real project. Lines that you should keep synchronised with "source of truth". People love Lombok for a reason. And most developers don't really care about implementation details, they believe that Lombok is "big enough" to work in the foreseeable future. It worked for them for years, it's supported well in Idea. I, personally, avoid Lombok, specifically because I care about implementation details. Because if I would have wanted better Java, I'd go with Kotlin rather than this hacky way of using another Java-like language. But other people hold different opinions.
      - cogman10 2y ago
        There are alternatives that don't rely on jvm internals to accomplish their goals. They do like 90% of what lombok does. Immutables and AutoValue are two examples I've used that work fine. The 10% lombok can do because it's peaking at internals isn't valuable. I don't, for example, need an annotation to create a static logger. That's dumb.
throwaway92422 2y ago
I like Lombok. The best annotation is @Builder. It makes working with records much more convenient.
- JanecekPetr 2y ago
  https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder The upsides are: - it generates code and does not do anything funky with internals, - it has a lot of knobs if you need something a little different. The downside is that it does not provide you with the other Lombok annotations. In practice that has been OK!
  - cogman10 2y ago
    Besides this I'd also point to Immutables and AutoValue which both can make builders without touching jvm internals.
xxs 2y ago
>Now, if only I could get devs to stop using lombok.... that's actually not too hard. It has happened to get them all converted to avid opponents of lombok.

sgammon 2y ago

> Now, if only I could get devs to stop using lombok One of the only remaining reasons I discard libraries without a further thought

pandemic_region 2y ago

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.

pests 2y ago

Been a long time since I used Java. I checked out lombok since you mentioned it. Does it really just internally create all those methods without there being actual source code? It seems nice but really spooky-action-at-a-distance feeling. Sounds like a nightmare.

DevelopingElk 2y ago
Yes, from a language design it's ugly and the implementation is convoluted. From a user perspective it's awesome and enables better interfaces.
- pests 2y ago
  I don't even agree with their demo video. It shows the "hard" way of autogenerating settings/getters, toString, hash, etc. The end result was like an additional ~80 boilerplate lines. I have no problem keeping those lines around.. opposed to adding the lombak.jar and changing my build config. I do understand the user perspective of it "just working" and of course the getters/setters will grow as you add fields... it just seems like such a low amount of code to keep around it shouldnt be too much hassle.
  - vbezhenar 2y ago
    It's not 80 lines. It's many thousands of lines in any real project. Lines that you should keep synchronised with "source of truth". People love Lombok for a reason. And most developers don't really care about implementation details, they believe that Lombok is "big enough" to work in the foreseeable future. It worked for them for years, it's supported well in Idea. I, personally, avoid Lombok, specifically because I care about implementation details. Because if I would have wanted better Java, I'd go with Kotlin rather than this hacky way of using another Java-like language. But other people hold different opinions.
    - cogman10 2y ago
      There are alternatives that don't rely on jvm internals to accomplish their goals. They do like 90% of what lombok does. Immutables and AutoValue are two examples I've used that work fine. The 10% lombok can do because it's peaking at internals isn't valuable. I don't, for example, need an annotation to create a static logger. That's dumb.

throwaway92422 2y ago

I like Lombok. The best annotation is @Builder. It makes working with records much more convenient.

JanecekPetr 2y ago
https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder The upsides are: - it generates code and does not do anything funky with internals, - it has a lot of knobs if you need something a little different. The downside is that it does not provide you with the other Lombok annotations. In practice that has been OK!
- cogman10 2y ago
  Besides this I'd also point to Immutables and AutoValue which both can make builders without touching jvm internals.

xxs 2y ago

>Now, if only I could get devs to stop using lombok.... that's actually not too hard. It has happened to get them all converted to avid opponents of lombok.