1. 5

  2. 9

    this seems like a rant about Spring Boot, JDBI, Postgres, Liquibase, and their dev environment, not java. the spring ecosystem is notoriously fiddly; I have utter sympathy for anyone using it for the first time, but this has little to do with java itself.

    1. 3

      Yes this. I REALLY wish blog authors would be a little more careful about word choice. s/Java/Spring/ and this is a really cogent, readable blog post with a legitimate axe to grind.

    2. 9

      Saw a huge block of XML, screamed and hit the back button.

      1. 7

        Poor framework choices cause a bad development experience in any language. This is particularly prone to happen in Java because most of the “de facto standard” frameworks are rubbish. To make elegant Java projects, you have to ignore 90% of the internet. Hopefully not this comment.

        1. 10

          In my experience, to write elegant Java:

          • Learn SML, Haskell, Lisp, or at least Python. By no means should you learn idiomatic Java. If you already know it, unlearn as much as you can.
          • Use Java 8+.
          • Never use any dependency with more than a handful of public classes.
          • Never use anything which uses reflection, annotations or inversion of control.

          At this point, you’ve basically got a very verbose Python that’s screaming fast and has basic static typechecking. I honestly prefer it.

          Also, for what it’s worth, I think (though I’m sure as hell not going to trawl through Spring’s garbage fire of “documentation” to confirm) that the author didn’t have to write as much boilerplate as they actually did; there are magic annotations to autogenerate at least some of that, like the mapper and probably the DAO as well. Note that this has absolutely no impact on their point (because none of this is discoverable without dealing with the pain yourself, cf. aforementioned garbage fire).

          1. 2

            Learn SML, Haskell, Lisp, or at least Python. By no means should you learn idiomatic Java. If you already know it, unlearn as much as you can.

            This gave me pause. So you’re advocating for people writing code that will be all but unmaintainable by the rest of the team in the name of elegance?

            I agree that learning other programming languages can make you a stronger programmer in your language of choice, but this strikes me as really unfortunate hyperbole.

            1. 9

              Given the specific list “SML, Haskell, Lisp, or at least Python”, I think what whbboyd’s actually going for here is “get comfortable writing simple programs that mostly pass values around, preferring simple uses of generics (i.e. parametric polymorphism¹) or interfaces (i.e. duck typing²) over doing unpleasant stuff with deep inheritance hierarchies, and not being scared of lambdas”, because that’s roughly the intersection (not union) of those PLs’ feature sets.

              (¹ fancy word for “when you put a thing into a list-of-Ducks, the thing you put in is a Duck, not an arbitrary Object” and “when you take a thing out of a list-of-Ducks, you get a Duck back, not a mysterious Object reference that has to be cast to Duck and which might throw an exception when you do that.)

              (² non-fancy word for typeclasses ^_~)

              This is an argument for writing less-complicated Java. I’d expect the resulting programs to be more comprehensible, not less, and they might actually look simplistic.

              This is not an argument for rewriting all your Java programs with the control flow implemented as Church-encoded data structures. That would be wildly incomprehensible.

              1. 4

                Precisely this. Java’s typical idioms are not conducive to writing elegant code, so learning better idioms instead will put you in a better place, and shouldn’t significantly affect the ability of competent teammates to understand and maintain your code.

              2. 4

                I agree that there is some hyperbole here, but I also do think the above commenter has a point. Java can be nice if you subtract the cultural gunk that has built up around “patterns”. The jOOQ blog covered it well, I think.

          2. 4

            How about not using Spring? Seems like the simplest way forward.

            1. 3

              Welcome to Spring.

              1. 1


                Betteridge’s law of headlines:

                Any headline that ends in a question mark can be answered by the word no.

                1. 1

                  The author has changed the title from ‘Can we make Java better already’ to ‘Can we make Spring better already’.

                  Looks like they got the message!