Java, My Precious: Or the identity crisis of a Java Veteran

Some see Java as a thing of the past. In fiercely trending AI, Python is all the rage. Frontend has mostly been a lost cause for Java developers for a long time, but node.js and other Javascript/Typescript technologies have gained ground in backend development, too. What is happening to My Precious? Is there a future for Java?

Yes, there is. Most Nitorean Java Gollums believe that the majority of enterprise backends will continue to run on Java or other JVM languages in the foreseeable future. Java offers many advantages in enterprise use, particularly in production instrumentation and debugging tooling, which are among the best available.

Currently, Java is considered the most secure language for writing services, especially when handling untrusted content like images. This security advantage stems from the ongoing process of “rewriting everything” over the past 20 years. In contrast, many other languages, such as node.js and python, often rely on linking to potentially unsafe C code for much of the functionality.

And it is not only Java. Other JVM languages, such as Kotlin and Clojure, are likely to gain more traction, meaning that pure Java use may slowly diminish in enterprise backends. Nowadays, many Nitorean Java Gollums prefer Kotlin when given free rein. This is because Kotlin is more concise as a language, but you can still practically use the entire Java ecosystem just as before.

Java and JVM languages are still useful in serverless environments, despite their reputation for long cold start times and relatively high memory usage. Technologies such as AWS SnapStart and native compilation with GraalVM can be used to reduce these cold start times, though they don’t change the game entirely. They are significantly beneficial in some cases.

However, Java Lambdas will never be as snappy as Lambdas written in Rust or Go, and developer experience of Typescript based Lambdas is hard to beat. Nonetheless, focusing solely on cold start times is foolish. For the vast majority of workloads, an occasional 2-second cold start is not a disaster. If the load is even somewhat consistent, cold starts are quite rare in real life.

From a programming model point of view, Java has it all. Reactive frameworks like WebFlux and Quarkus allow you to create asynchronous, non-blocking solutions. The trip is arduous, though: to go fully reactive, one must adopt an entirely new way of thinking. Unit testing and debugging reactive solutions can also offer some challenges, but it’s important to note that they are not unique to Java or other JVM languages. Reactive programming is different in any environment.

But Java programmers don’t actually have to do this – we get reactivity for free! The introduction of virtual threads in Java 21 is a game changer. They offer the benefits of non-blocking solutions while using code that is easy to understand and debug. Once major frameworks and drivers fully adopt virtual threads, they will be a boon for server side Java development.

Java Gollums can survive and even prosper in the future. It pays off to learn more recent Java stuff than Java 8 and Spring Boot – but these two will still be sufficient for the majority of Java work in the near future. Wise Java Gollums will start looking for other Rings, too, and exploring other JVM languages is a natural step. Node.js / npm ecosystem in Typescript is not that difficult to master with a strong Java background.

All in all, there is no need for an identity crisis for Java veterans. The Ring may not be as bright as it once was, but My Precious remains beautiful. Especially so, when we embellish it with an odd Kotlin or Clojure stone and keep abreast of the language’s development. Yes, Precious, we still loves you!

If you want to dig deeper into recent developments in the world of Java, have a look at my colleague Ville Saalo’s blog on State of Java.