What's wrong with Java? Nothing, but evaluate alternatives

Speed

Java is far from slow. It is orders-of-magnitude faster than Python, and for the vast majority of problems it is more than fast enough to provide a well-performing solution.

However, at the end of the day Java is still a bytecode intermediate language. Java's strength of portability is also a weakness in some situations.

Some problems simply require native code. Examples include operating systems, or systems that must work at near real time, or anything where the last millisecond of performance is important.

The venerable C and C++ languages are obvious choices here and would do the job well, but they lack many modern features such as built-in common data structures. More modern languages such as Go and Rust have the benefit of being native code, and still provide a rich package infrastructure and solid built-in support for common data structures.

Complexity

A common charge leveled against Java is that the language is complex and requires a lot of boilerplate code just to do simple things. To a degree this is false; Java is really not much more verbose than most C-descended languages, and recent revisions have taken steps to reduce this verbosity.

However, other languages are undeniably more concise. Python obviously comes to mind here, as do JavaScript and Mojo. Some argue that reduced complexity increases developer output, as the cognitive load is less, although I'm not entirely sold on this argument. Still, I have written production code in both Java and Python, and in the early stages of a project it is undeniably easier to pivot and make major changes in Python or JavaScript than it is in Java.

Later in a project, where it is more stable and the architecture is settled, there is little difference making changes to a Python or JavaScript project than there is to a Java project.

Runtime fragmentation

This is a valid criticism of Java. Of all the languages that use a runtime, none are as fragmented as Java. Java runtimes stretching all the way back to version 8 are still in common use today.

Python, the .NET languages and Mojo all have mostly heterogenous ecosystems on the last few versions of the runtimes.

The same criticism of runtime fragmentation can be leveled at JavaScript and TypeScript, which still use numerous versions of Node and Bun. Even so, they are less fragmented than the legions of JVM versions still in everyday use.

There have been major changes from Java 8 language to the present day, and this can be difficult to account for when you deploy code in different environments. If you completely control the deployment environment, this is less of a concern.

Package support

Package support is strong in Java, with many packages to help provide prebuilt components. However, the package system in Java is rather complex compared to other languages.

Python has a well-integrated and simple-to-use package mechanism in PIP, as do the .NET languages with NuGet and JavaScript/TypeScript with NPM. Even Go has simple package support right from source repositories. All these alternatives to Java also provide simple ways to publish to the package repositories.

By comparison, Java's system using Maven feels archaic and overly complex. It requires specially crafted XML, which is reminiscent of old C make files.

In recent years, the package libraries mentioned above have begun to eclipse Java. Some of the newer packages are simply not written in Java.

Verdict: Alternatives to Java work, too

There's not really much wrong with Java; it's a great choice for a general-purpose programming language. Nevertheless, developers should always use a language for what it is good at, and that means considering all languages for what they are good at if they meet your needs.

It's a mistake to rigidly rely on one set programming language. Be open to using the best language for the task at hand, whether it's Java or one of many suitable alternatives.

David "Walker" Aldridge is a programmer with 40 years of experience in multiple languages and remote programming. He is also an experienced systems admin and infosec blue team member with interest in retrocomputing.