• cAUzapNEAGLb@lemmy.world
    link
    fedilink
    arrow-up
    1
    ·
    7 months ago

    I fucking hate Spring.

    The quickest way to get a team of 10 contractors to turn 100 lines of basic code from a decent engineer into 2k, with 50 janky vulnerable dependencies, that needs to be babied with customized ide’s and multi-minute+ build times and 60m long recorded meetings.

    Fuck Spring.

    • MajorHavoc@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      7 months ago

      Fuck Spring.

      Actually, there’s a lot to be said for being able to configure your spleamtomoter without needing to reverse the polarity on the stack cache rotator arm.

      I’m kidding.

      Fuck Spring.

    • passepartout@feddit.de
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      edit-2
      7 months ago

      Wouldn’t want to write a webserver / database connection / scheduler / etc. from scratch. Spring Boot plus lombok turns 2k lines of code into 100.

      • expr@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        Sure… That"s what libraries are for. No one hand-rolls that stuff. You can do all of that just fine (and, actually, in a lot less code, mostly because Java is so fucking verbose) without using the nightmare that is Spring.

  • Riley@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    6 months ago

    As an audio engineer, I was very confused about what this had to do with Direct Injection for a second.

  • Krakaval@jlai.lu
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months ago

    Can we talk about annotations which are broken when you upgrade spring boot ? You are asked to upgrade some old application to the newest version of spring boot, application that you discover on the spot, the application does not work anymore after the upgrade, and you have to go through 10 intermediate upgrade guides to discover what could possibly be wrong ?

    • frazorth@feddit.uk
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Gradle, with it’s transitive dependency modifications is a huge pain in this area.

      It used to be that if a library ended up having a flaw then it would be flagged and we would get the dependency updated. These days security block the “security risk” and you have to replace your dependencies dependency. Fingers crossed you can get it to actually test all the code paths.

      If an second level project gets a flaw, and it’s used indirectly then we should really look at getting the import updated so that we know it works. If that import is abandoned then we should not be updating that second level dependency, either adopt and fix the first level dependency or look at an alternative.

    • setVeryLoud(true);@lemmy.ca
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Holy shit mood, described to the tee.

      An application I’ve never heard or seen before that needs to be upgraded, and it breaks, so you now need to understand what the hell this application does so you can fix it properly.

    • AggressivelyPassive@feddit.de
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Spring annotations in general. There’s a completely hidden bean context where every annotation seems to throw interceptors, filters, or some reflection crap into. Every stacktrace is 200 lines of garbage, every app somehow needs 500mb for just existing and if you add something with a very narrow scope, that suddenly causes something completely unrelated to stop working.

      Realistically, DI and all the Spring crap does not add anything but complexity.

  • davidgro@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    I think this might be the first of these I’ve seen where pretty much all the comments are just agreement.

  • Mikina@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    My favourite take on DI is this set of articles from like 12 years ago, written by a guy who has written the first DI framework for Unity, on which are the currently popular ones, such as Zenject, based on.

    The first two articles are pretty basic, explaining his reasoning and why it’s such a cool concept and way forward.

    Then, there’s this update:

    Followed by more articles about why he thinks it was a mistake, and he no longer recommends or uses DI in Unity in favor of manual dependency injection. And I kind of agree - his main reasoning is that it’s really easy for unnecessary dependencies to sneak up into your code-base, since it’s really easy to just write another [Inject] without a second thought and be done with it.

    However, with manual dependency injection through constructor parameters, you will take a step back when you’re adding 11th parameter to the constructor, and will take a moment to think whether there’s really no other better way. Of course, this should not be an relevant issue with experienced programmers, but it’s not as inherently obvious you’re doing something potentially wrong, when you just add another [Inject], when compared to adding another constructor parameter.

      • frezik@midwest.social
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        It was a markup language until someone decided to parse and execute it as a programming language. This person should be watched for other deranged behavior.

      • steventhedev@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        7 months ago

        Whoosh

        Seriously though, spring configurations are written in XML and you create variables, call functions, and have control flow. Effectively turning XML into a horrible twisted shadow of a programming language.

        All in the name of “configurability” through dependency injection.

        • lars@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          7 months ago

          Spring moved away from XML ages ago. I work on a 6 year old Spring project and it has never had a single line of XML in it.

          • MajorHavoc@programming.dev
            link
            fedilink
            arrow-up
            0
            ·
            7 months ago

            I’m fond of saying that all great code earns it’s right to become good code by starting as trash…

            But I still think we should all quietly and politely let Spring die a simple dignified death, as soon as possible.

            Out of wildly morbid curiosity, do Maven and Ant still shit all over each other to make sure no one has any real idea what the build inputs and outputs are?

            I shouldn’t ask things I don’t really want to know, though. My inbox is gonna be full of Java apologists.

  • Solemarc@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    7 months ago

    At work we have a lot of old monolithic OOP PHP code. Dependency injection has been the new way to do things since before I started and it’s basically never used anywhere.

    I assume most people just find it easier to create a new class instance where it’s needed.

    I’ve never really seen a case where I think, “dependency injection would be amazing here” I assume there is a case otherwise it wouldn’t exist.