Java champions and Senior engineers speaking out against lombok

    • Custodian6718@programming.devOP
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      edit-2
      10 days ago

      thanks for extracting the original post. i only put the linkedin as a source because you can clearly see java champions on social media speaking out against lombok (which you obviously cant on the original post)

  • Lysergid@lemmy.ml
    link
    fedilink
    arrow-up
    6
    ·
    11 days ago

    Never had an issue with Lombok. Though I use only getters, setters, constructor and sneaky throws. And I don’t know what exactly they want to debug. It’s literally assignments in most cases. According to such logic, should all reflection based tool be removed too? I guess remove “bad” Spring and JPA/Hinernate then? What a nonsense

    • Von_Broheim@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      2 days ago

      I thought that the whole point of Lombok is that it’s not reflection based, they explicitly refuse to use reflection as a design principle. Afaik lombok statically generates methods and classes at pre compile. That’s why for example lombok does not support constructor inheritance or overloading.

  • McMonster@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    10 days ago

    Anything that does under-the-cover low level magic is bad. The deeper the magic, the worse. Spring is the particular offender here with the lengths it goes so to make you not use new and never be able to debug why something happens. Or worse, why something doesn’t happen. We know how to deal with code, but not magic.

    • Von_Broheim@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      2 days ago

      There’s no magic in lombok, they’re just meta annotations for class generation, no different than having each end every class implement some very specific interface exactly the same way every time. It’s for reducing copy pasting. Debugging it is not a problem, especially that you can see the generated classes in the library files. Spring on the other hand is a black box, because it does too much and has become very bloated over the years, the goal of Spring is not to avoid using new the point is simplifying dependency injection and composition. The most fried part is the transaction management imo, because it’s too delicate in the way it has to be configured.

  • state_electrician@discuss.tchncs.de
    link
    fedilink
    arrow-up
    2
    ·
    11 days ago

    I never saw a benefit in using Lombok, but I did run into issues with it. As it works outside the compiler, you are basically writing Java+Lombok. And as the article says, with an IDE and a recent JDK there is really no benefit provided by Lombok.

  • glorkon@lemmy.world
    link
    fedilink
    arrow-up
    2
    ·
    11 days ago

    I personally switched from Java + Lombok to Kotlin. So Lombok isn’t really needed anymore.