What does the future hold for Java?

To better align with the tech stack at my new job, I’ve been reacquainting myself over the last two weeks with an old friend: Java. Not too long ago, it kickstarted my software career with unmatched zeal and vigor. This journey lasted for roughly two-and-a-half years but soon diminished with the advent of containers and microservices. Fast-forward to today, and it’s been three years now since I last wrote any serious Java code. And in all honesty, I never expected it to see it again — especially in the microservices landscape.

So, what happened? The answer is simple: The pervasive wave of microservices engulfed us.

• Ease of scaling
• High availability
• Simpler code base from not having to worry about concurrency and multi-threading
• Portability benefits from containerization

All of these factors prompted us to question the efficacy of Java (more specifically, JVM), not to mention its most notorious framework, Spring.

At times, with hands immersed in tech like Kubernetes, it felt like Java’s time was almost over and that it didn’t hold up well in the ecosystem of containers and microservices (which was key to software scalability and high availability). But as a once-staunch supporter of Java — and despite having been swayed by the simplicity and elegance of languages like Python (which has now grown to become my go-to language) — I still continued to hold a reserve for some of Java’s undeniable merits.

For instance, I was well aware of Java’s powerful threading capabilities, having used them firsthand early in my career for critical banking applications. While it’s not fair to compare performance metrics of a compiled language with scripted languages, Java’s rock-solid performance was simply unmatched.

But in the world of horizontal scalability and microservices architecture, this innate performance of a language mattered too little, for one could simply spawn more containers to achieve far superior performance. Clearly, these scripting languages, combined with their ability to instantly scale up or down in the land of containers, were giving Java a good run for its money. I was fully convinced, once and for all, that Java was done (at least in the land of microservices). And I was right!

At my new job, these convictions have only further strengthened and painfully made me realize how irksome, irritable, and convoluted the language has become — partly due to anachronistic ceremonious frameworks like Spring.

The Ceremony of Java and Spring

Let’s start with the notorious Spring framework.

Spring is as bulky and convoluted as it was five years ago, riddled with interminable annotations that leave developers at the mercy of tutorials or sample code every time they need to get things done. It’s either that or the arduous task of perusing Spring’s own exhaustive documentation.

My beef, in fact, is more with frameworks like Spring than Java itself. Spring adds to the problem by taking an already ceremonious language, veiling it with one-line annotations and seemingly reductionist wrappers that end up summoning a carnival of invocations and instantiations of classes that you often don’t need. As any developer would agree, control, command, and transparency of a language are crucial to efficient software development. Quite simply, as a developer, you want to know precisely what goes on in your code and what routines are executed — at least at a high level. But Spring painfully deters you in this aspect.

If you have to drop six annotations on top of your class, with each one doing its own thing, intricately interconnected in the mesh of spring contexts, you are in murky territory. And this is not just Spring. Take, for example, the Lombok library. This is its front line as advertised on their homepage:

“Project Lombok is a java library that automatically plugs into your editor and build tools, spicing up your java. Never write another getter or equals method again, with one annotation your class has a fully featured builder, Automate your logging variables, and much more.”

This regurgitated goal of compacting Java’s code is frustrating and painfully works against the language rather than doing any real good.

Java should simply stop trying to match the brevity of scripting languages. Firstly, this sacrifices consistency in Java code: Imagine coming back to Java only to find all your getters and setters gone (something we once learned was critical to Spring autowiring), now replaced with the one-line annotation @NoArgsConstructor. Where is the consistency in that?

Secondly, it adds to the already convoluted array of abstractions. Here, for instance, Spring is understandably setting up autowiring (bean injections) behind the scenes, but then where does Lombok live in the application context and how is message passing orchestrated between the two? If I have six annotations for each of my classes, how many other routines or classes were instantiated by these annotations to do this simplistic job? No real developer would want all this extra code lurking in the corners. Sadly enough, this is the kind of Java code I run into after three years. Not a single thing has changed. In fact, even the little changes that have happened have only made it worse.

Java’s focus still appears to be on silly rules that dictate what class names should be, what packages they should be in, and if variables should be private or protected. Seriously, who cares?

In contrast, “We’re all adults here” is literally Python’s official response to the absence of access specifiers in the language. This derisive yet compelling one-line response instantly struck a chord with me. It finally provided some sanity to a concept that I often felt was absurd and unnecessary.

Keep It Simple, Stupid

If there’s one thing that you’ll hear time and again in the software industry, it is the acronym KISS: Keep it simple, stupid. This is something Java needs to consider seriously if it wants to survive.

Today, the microservices pattern has almost become ubiquitous in the software industry. Even many organizations running legacy applications are increasingly replacing their old monoliths to simplify design and improve scalability. For programmers, this means that their massive code base or the complex business logic would be broken down into simpler and concise functions — a paradigm that eliminates the need for state management in the code, relieving us from concurrency problems and multithreading nightmares.

At the end of the day, all services, in some shape or form, merely process data in some format (JSON or XML) and then pass them on to a message bus like Kafka for further processing. And even in a ridiculously simple setting such as this, Java and Spring continue to regurgitate anachronistic rhetorics of ceremonious code syntax, Application Contexts, convoluted bean injections, autowiring, POJO mappers, memory-hungry JVM, and the infamous class loader — all of which are pointlessly painful to deal with.

The verdict? “Keep it simple, stupid!”