In this article, we’ll debunk the notion that Java is a relic of the past and showcase the language’s modern features, thriving ecosystem, and unwavering presence in enterprise and open-source communities.

  • @[email protected]
    link
    fedilink
    107 months ago

    I’m normally working in Kotlin when coding because I do Android development. I’ve had the misfortune of taking up some slack in a greenfield backend project and holy God is it miserable.

    Everything is harder to read, every basic data model is 200 lines of getters and setters, multithreading is painful, basic transformers require separate class declarations. And that doesn’t even touch on the horrific experience of using Jackson to handle json serialization.

    • @pprkut
      link
      5
      edit-2
      7 months ago

      I felt the same way coming back to Java from Kotlin. The more streamlined syntax of Kotlin is so much more comfortable to read and write. That being said, I never had an issue with using Jackson for JSON serialization in Java. I’m curious what issues you have encountered and if you have any alternative suggestions that are nicer to use in Java?

      • @[email protected]
        link
        fedilink
        27 months ago

        I’m not sure there’s much that is better or worse than Jackson. When I worked exclusively in Java I was always using GSON and did not remember having so many hoops to jump through. Could just be my bad memory though.

        I just feel like when I’m doing Java work I spend 90% of my time on useless boilerplate.

    • @BlueBockser
      link
      47 months ago

      Lombok will shrink the 200 lines of getters and setters to one or two. It has its own pitfalls of course, but IMO it’s definitely worth it.

        • @BlueBockser
          link
          17 months ago

          Definitely agree that Kotlin is so much better than Java + Lombok, but it’ll take a lot of time for all the existing Java projects or migrate to Kotlin or reach EOL. In the meantime, it’s hard to avoid the occasional Java project…

          • @[email protected]
            link
            fedilink
            17 months ago

            Sure but you can also just drop kotlin into any Java codebase. It’s a single line maven import and the entire company already uses Intellij

            • @[email protected]
              link
              fedilink
              English
              36 months ago

              Oh yeah - the seamless Java/kotlin interop is pretty slick, though there are some pitfalls - nullity is one of them. Kotlin treats it explicitly, but when it’s talking to Java, it’s forced to treat it ambiguously unless you wrap stuff in Optional. And then even if you do, some Java lib that you need to plug into your project might not do that, so you’ve got to be careful about managing the interactions between their interfaces in some situations. And then there’s the unfortunate divergence that’s started to occur as newer versions of Java have brought certain features that were first available in Kotlin into Java, but the patterns and interfaces often differ subtly, so you have to worry about that too, especially with less experienced engineers on the team.

              Don’t get me wrong - it’s great, and I’ve enjoyed working with it, but if you’re doing an incremental migration, make sure you test the ever-loving shit out of it.

              Source: I did an incremental Java -> Kotlin migration on a huge project a couple jobs ago

              • @[email protected]
                link
                fedilink
                16 months ago

                Yeah it can be slightly hairy because Java does a terrible job with nullability. I’ve also done an incremental migration of an android codebase to Kotlin.

                Personally I think being forced to declare the nullability of a field is something backend developers should do more of. It helps eliminate some of the foot guns that otherwise get built into the code base.

                I’m a bit of a kotlin fanboy though, I’ll admit.

                • @[email protected]
                  link
                  fedilink
                  English
                  16 months ago

                  I 100% agree that explicit nullity is categorically better, and the vast majority of the entire software engineering field does too. The problem lies in the fact that explicit nullity was added in 2014 with Java 8, nearly two decades after Java 1 shipped in 1996. That’s a hell of a lot of technical inertia to overcome.

                  • @[email protected]
                    link
                    fedilink
                    16 months ago

                    Yeah especially whether Java “runs on 1 billion devices” 😂

                    The question is why a new codebase in greenfield is still using basic Java 11 on a new 2023 project.