Time to Retire Java

Hi. Are you working with Java? Do you still enjoy it? Really? We need to talk.

I started learning Java in 2004. I’ve been working with it professionally for the last 6+ years. It’s been a good journey. I still remember what an applet is. I’ve written enterprise desktop applications using Swing. I remember the time Java jumped from version 1.4.2 or whatever to Java 5, but then actually it didn’t.

For the last couple of years though, I’ve been feeling that this journey is coming to an end. Not just for me, but for the whole community. I’ll try explaining the reasons behind it and share my vision of Java in the future.

From Leader to Follower

When I first heard about Java 8, I remember myself thinking: “Ha, joke’s on you, Scala, nobody needs you anymore!”

Of course I didn’t say it out loud, but still, that’s actually a pretty sad conclusion. In the early years of Java it was all about change, innovation, about making programmers’ lives easier. Platform-independency. Garbage collection. A solid and usable object oriented approach. Those were the things that made it so popular. But by the time a new language using the JVM emerged with a serious agenda, Java was no longer a leader, a pioneer, but a mere follower of trends. It changed only when it absolutely had to. It stopped bringing any new exciting methods, new ways to think about programming. It just started copying existing ones once they became too popular to ignore. Still, that’s not the worst thing about Java today.

Effectively Killing Java

Every competent Java developer will be proud to say that Effective Java by Joshua Bloch is one of their favorite books on programming, even if they have not actually read it. I have still yet to read it cover to cover to be honest. Nevertheless, every time I went back to read parts of it, it’s been the number one cause of disenchantment from Java for me.

When you consider some of the tips, tricks and workarounds that are still relevant today, you are going to see that some very basic shortcomings of Java have not improved a bit for the last 16 years since the book first came out, even though millions of programmers around the world have to face those challenges every single day.

We still need to use the Builder pattern for building objects with many parameters, which usually more than doubles your code, with a lot of duplication.

Using enums is still the best way to create Singletons. Which is weird when you think about it. I mean, really? Enums?

And for me, the most annoying part: We still have to use the ‘final’ keyword everywhere to ensure reference immutability. Especially now that we have functional programming features in Java such as lambdas and higher-order functions which should’ve discouraged you from using mutable variables, this feature seems even more important than before. Yet, it is such a core feature of Java that we can assume it’s never going to be resolved unless it radically reinvents itself. You have mutability by default, and you need a 5-character keyword to override it. That’s the Java way. And now it’s easier than ever to realize that there is something fundamentally wrong about this.

In a sense, many of the weaknesses pointed out in the book are still very relevant today, and the fact that at least some of them will probably never be resolved is effectively killing Java. Especially since we have the alternatives.

Rise of the Polyglot JVM

JVM has been one of the strongest and most marketed aspects of Java since its birth. However, compilation into bytecode not only ensures platform-independency — it also brings language-independency and kind of makes Java irrelevant. You don’t need Java to work with the JVM and can still use years of experience, development and community support around it.

When you look at the world of programming today, you will see many JVM-based languages. There is a really high level of competition in that area. Most of them fail at becoming widely accepted, but some of them (Scala, Kotlin, Groovy etc.) have reached enough success and popularity to be candidates for… replacing Java itself?

When you take a look at those languages — especially Scala and Kotlin — you’ll immediately realize that they have specifically targeted the problems described above. With named parameters, you no longer need the Builder. Variable definition through the short & enforced var-val keywords is more elegant than favoring mutability. You can create singleton objects by simply writing “object” instead of “class”. And a bonus: With data/case classes, you no longer need to write and maintain default hashCode, equals and toString methods, which are painful to maintain in Java even if you generated them automatically thanks to your cool IDE.

Simple data class in Java vs. Kotlin

These features help these languages easily overcome the weak points of Java, while still making use of the huge JVM ecosystem. You can keep using any library, framework or build system (at least the most popular ones) you’ve been using with Java and effortlessly migrate to another JVM-language.

Now, some people may suggest using Project Lombok and getting all of those cool features while still writing Java. I do not object to it (it might actually help convince more people to switch languages in the end) but I have my concerns. To sum up: If you feel the need to use a 3rd-party library to fundamentally change the way you code, why not drop that language completely and switch to something else? Having those features in the language itself is probably a better idea than relying on a library.

Also keep in mind that the features described above represent only the tip of the iceberg: new generation JVM languages, and especially Scala, are quite powerful in all aspects and are full of other useful features that will change the way you think about programming, in a positive way. But I’m not going to give you an extensive list. Let’s instead talk about Java’s future.

Java as a Reference Language

Java is old and resistant to change. We had to wait for Java 8 to get not just lambdas but even a decent Time API that doesn’t make you want to kill yourself. None of the problems in this article are going to be resolved in Java 9 or even 10. As much as I respect the language designers, and the Java community, I think its practical value as a programming language is in a decline and it’s almost impossible to reverse that trend now.

Java might be able to take radical decisions and re-invent itself as a modern language at some point, but by doing so it would reduce itself to being yet-another-JVM-language. I doubt the community would welcome that.

Instead, I think what Java should and will become in time is sort of a reference language for the JVM. Whenever a new JVM version is rolled out, Java will be the go-to reference to find out about the new features native to JVM itself.

But in daily, practical use it’s probably going to become less and less relevant. Not right away, not tomorrow, because we all have a ton of legacy code to maintain and millions of potential teammates and employers still in love with Java. Yet the fade-away will be faster than you probably think.

Even though this article is based mostly on my instincts and subjective experience, Stack Overflow Developer Survey actually contains hints about this. Java is no longer #1 on the Top-Tech list. It’s been on a slow but steady decline on the lists of Most Popular Technologies and Trending Tech. I doubt this year’s results will be better, especially since Kotlin got officially endorsed at Google I/O and many Android programmers are already -happily- abandoning Java to start using Kotlin.

So, you may want to re-invent yourself especially if you’ve been a ‘Java developer’ for too long. Start now rather than later and it will prepare you for the future. And you’ll probably enjoy programming a lot more while doing that.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.