Java Isn't Dying

Today's entry in the Betteridge file. Is Java Dying? True to Betteridge's law, no. It's one of those perennial questions, and the answer has always been the same. It fills a need, and it's been deployed to production in countless places. And as COBOL reminded us yet again this year, if it's in production it will never die.

And if you look at the Java ecosystem, it's actually growing, JVM languages continue to grow and evolve. Scala is a fairly functional language on the JVM, and Apache Spark is written in Scala. For you LISP fans there's Clojure. If you're developing for Android there's Kotlin. And of course, if you want COBOL MicroFocus has Visual COBOL. So developing in/on/with Java is far from dead.

And with all those different languages, there are some deeply ingrained Java/JVM use cases. For example, a lot of distributed processing, from general MapReduce to ML training to Log processing uses PySpark. Yes, there's a lot of Python written to process the data, but under the hood it's Spark and the JVM (Scala) doing the heavy lifting.

Even if you don't use PySpark you're using Java every day at work, even if you don't realize it. Our monorepo is on the large side. And keeping track of dependencies and what's up to date vs what needs to be built is rather complicated. So we use bazel. And bazel is written in Java.

Yes, Java is verbose. So what? You've got an IDE to help you. A bigger issue is dependency management. Yes. transitive dependencies can be hard to manage, and sometimes they can even lead to incompatibilities, where one dependency you have transitively includes version X or something and another includes version Y, but there's no version that makes them both happy (I'm looking at you guava). But you know what? Java at least has a way around the problem, the shaded JAR. If you need to, you can include both versions and the correct one will be used by each part. If you think that's ugly, try looking at npm and what gets dragged into the simplest Javascript web app. Now that's scary.

But really, none of this matters. Because the programming language you use is a tool. A means to an end, Not the end itself. I'm not using Java right now for my current work, and I probably wouldn't choose it if I found myself in a situation that really was a blank slate and there was nothing pushing me in a direction, but really, how often does that happen? I'm working with Kubernetes, which pushes me towards Go. There's also a lot of libraries/functionality around Kubernetes and gRPC which makes Go a good choice. When we built/ran Opus, which grew up in a Spark/Hadoop world, we used Java and Scala because that's what the rest of the tools we needed to talk to used. And it was very successful.

So don't worry if the language is alive or dead. Look at what's being used to solve the problems you're solving by the people you'll be solving them with. And use that language. It's good to have the discussion about what language/framework to use, but if there's something in use, you should probably use it.