Old fashioned

Yes, the base constructs and constraints that Java offers are old fashioned and rely on how code was written 20 years ago. Programming languages are not created in a sterilized bubble. Developers’ habits and needs are central to language design, and while inventors try to infuse innovation in it, it’d be dumb to ignore how people will actually use it. The first milestone for Java dates back in 1995, and while some of its foundational blocks looked visionary for at least 10 years, it is pretty obvious that 24 years later… not so much.

It’s not just a matter of time though. In the last 10 years, lots of things changed drastically in this field. Some of these things may seem unrelated to this topic, but they’re actually central to the discussion.

For example, the greater availability of cheap memory played a central role in the mass re-adoption of functional programming in production software. Which is then related to the adoption of the reactive programming manifesto.

Accessible and manageable cloud computing eased the conceptualization of the microservices model, which found its production role when containers became real.

The microservices model then gave dignity to programming languages that are exceptionally suitable for certain tasks, but less brilliant for others.

It doesn’t end there. The new challenges imposed by big data lead to the invention of new task-optimized database systems, capable of ingesting a humongous amount of data, which then had to be analyzed. This actually didn’t cause the birth of new languages, but a second-thought on existing languages that proved to be perfectly suitable for this task.

Not to mention the second youth of artificial intelligence scrambled everything again.

But wait a minute…

Python is now sort of the golden standard for machine learning, but if you have a quick look at its Wikipedia page, you will soon realize it’s older than Java and dates back in 1990!

What about R, a common choice for data analysis? 1993.

JavaScript? Curiously, 1995, just like Java.

Erlang? 1986…

Why are these languages not considered old fashioned but Java is?

Because we changed, and with us, our challenges.

Python, for example, has always been a fantastic scripting language for utilities and data processing programs but generally considered unsuitable for fat enterprise applications. But microservices are — generally — small programs and data pipelines are made up of small, well defined, mostly functional steps.

JavaScript has always been the sole solution to make web pages dynamic, but with the proliferation of complex web applications, it was reasonable to bring it on the server side as well.

To conclude, the reason why Java is considered old-fashioned is that it is well suited to build fat, mostly monolithic applications, with millions of lines of code, requiring a lot of planning and rigorous order which Java requires by design.

Try to do the same with JavaScript, and you will quickly realize that “death is not the end, but only a transition” (cit.).

Ineffective

Relatable.

I often use this metaphor to explain Java:

If you need to build a matchbox, you first take 10 tons of lumber, build a log, then whack it down to a matchbox.

As Java imposes a formal, rigorous approach that encourages the creation of proper class hierarchies, it is unavoidable to end up working like an idiot to set everything up in the proper way, even for a very tiny task.

And that’s the thing. Given what we said in the previous chapter, no easy task stays easy in Java.

Note that by easy I don’t mean easy to implement, but easy in terms of architecture. Writing intricate algorithms is a hard task and I find it easier to do in Python.

It’s quite obvious at this point that we’re iterating over the same concept: the right tool for the job.

Java is (and has been) a very general purpose programming language and has been used to solve all types of problems, in all kinds of scenarios, but as time progresses and challenges change, it seems more and more obvious that Java is not immune to specialization anymore, not because it has evolved into a specialized language, but because of the great suitability of other languages in specific tasks.

If you’re building a large scale enterprise platform (or at least the central node of it) with lots of internal orchestration, huge codebase, crazy parallelism etc. Java is still a beast. Wait, is it…?

Java is doomed

Sort of, as explained in this dark motivational quote: “Don’t be afraid of the future, you won’t experience much of it”. You should be LOLling at this point…

Java is pretty much like a developer as he’s ageing. You’re not as clear-headed as you were 10 years ago, but wiser, more stable and reliable. Sure, you can still learn Rust, but it will never feel as right as it feels for a person 10 years younger than you. In the very same way, the race to modernize Java is constantly running behind and when the new features come out, you have the impression they are becoming reality years after the proper timing. When they first introduced lambdas, for example, the reaction was not “Yay! Let’s party!” but more “For God’s sake what took you so long?”.

On the other hand, people fail to realize that the greatest achievement of Java is not the language itself.

An exceptionally good ecosystem

What still brings me back to Java when planning big sized software is the ecosystem. Superb quality libraries for anything you can dream of all over the Internet.

Think about Spring, Akka, Tomcat, and I could name hundreds. These are not garage projects, but extraordinary achievements. I don’t mean this cannot be done in other languages, but the way the big business propelled Java created the preconditions for such software to come to life. It took years to get here, and the time factor is also very important as 20 years on the edge is a long time for the ecosystem to mature.

You can find exceptional libraries for many languages, but you quickly realize whether they exist or not depends a lot on whether a large company endorsed the project.

For example, it’s super easy to find good machine learning libraries for Python, and you can’t say Google didn’t play a role in it, you can develop brilliant web applications with React.js (Javascript) thanks to Facebook.

You actually mean the JVM

The biggest achievement of Java, other than its huge ecosystem we previously mentioned, is the JVM. While the language may suffer its age, the JVM looks well and healthy for what us regular humans can understand.

Now, some may say that containerization killed the need for a JVM and in some sense that is the case. The original need for the JVM was, in fact, to allow a program to be executed on any OS, but containers changed everything in that regard, as a container provides a simulacrum of an OS that can be executed anywhere (on paper).

But the JVM has become more than that. Memory management and garbage collection, security, fundamental programming libraries, debugging and inspection capabilities. All these items made the JVM a very safe, comfortable place to be.

“But the JVM is so HEAVY and SLOW!” this is a classic pushback I receive, and while this is partly true in its memory footprint and bootstrap times (which makes it quite unsuitable for task-oriented programs), from the performance point of view, a few things happened in the last 20 years or so.

Here are a few benchmark comparisons using popular algorithms.

While this kind of benchmark doesn’t do justice to the involved languages because algorithms are just part of the story, you can clearly tell that the JVM is definitely not a sick elephant dragging itself to the graveyard.

However…