Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What Will Kill Java?

DZone's Guide to

What Will Kill Java?

Java is one of the most popular languages on the planet, but the competition is heating up. Here's where Java might falter and what can be done to prevent it.

· Java Zone
Free Resource

Build vs Buy a Data Quality Solution: Which is Best for You? Gain insights on a hybrid approach. Download white paper now!

The TIOBE index for September 2017 listed Java as the more popular language of that month. In fact, it has been in the top three for many years now.

The Stack Overflow Developer Survey 2017 listed Java as the third-most commonly used programming language after Javascript and SQL (actually, this hasn't changed in the last four years).

Independently of how these results are generated or if they reflect what happens in the real world, we can't deny that Java is still a popular language in more than one environment.

However, Java will die someday. Nothing lasts forever.

The true definition of a dead programming language is one that no one uses anymore — but that's very hard to happen. Even old and not widely adopted languages (for example, have you heard of Modula-3?), are still used, maintained, or at least, evolved into something else.

Of course, this is a gradual process, and there are several ways it can happen. For practical terms, let's consider that a programming language is dead when it's not used in new projects anymore, although it may live on many legacy projects (COBOL is the perfect example).

As this will happen to Java eventually, what will kill it?

Let's analyze the options.

In his talk, What Killed Smalltalk Could Kill Ruby Too, Robert "Uncle Bob" Martin says that what killed Smalltalk was that it was too easy to make a mess and that there was an arrogance that led to unprofessional practices, like the lack of test-driven development (TDD).

You can make a mess in any language. Sure, in some languages, it is easier to make a mess than others — for example, in dynamically typed languages, where we can change the types of variables at any time — but we don't have that problem in Java.

Also, there has been a good rate of adoption of good practices in the Java community, like design patterns and TDD, that have helped us make better software.

So let's explore another option.

Java is an object-oriented language. What if some other (new) paradigm takes over? What if object-oriented programming becomes obsolete?

Well, that's not very likely — the fundamentals haven't really changed a lot for a long time. Major innovations like structured, functional, and object-oriented programming occurred in the 1950s, 1960s, and even 1970s, but since then, we have seen nothing of that importance.

However, in the last decade, there's been a lot of new languages with modern syntax and frameworks with new features.

So, will the lack of modern syntax and features will kill Java?

No, I don't think so.

Do you remember (or hear about) EJB 2.0 and its Entity Beans? They were awful, but members of the Java community like Rod Johnson and Gavin King responded with frameworks like Spring and Hibernate.

In a similar way, Java is not a fully functional language, but thanks to libraries like Vavr, we can make Java more functional.

What I mean is that if Java is missing something, someone will create something (a framework, a tool, a specification, whatever) to fill that void.

So will it be another programming language?

Let's take JavaScript, for example. After all, JavaScript is eating the world, right?

We could use Node.js in the backend, something like React Native or Ionic on mobile, and let's not even mention all the options we have on the frontend.

However, at least in enterprise software, I don't see JavaScript replacing Java in any future. JavaScript doesn't have the frameworks or the tools to succeed in the enterprise world. It also doesn't have something comparable to the Java Virtual Machine (JVM), the platform of choice for big and mission-critical software.

And what about Kotlin?

Kotlin is a language that first appeared in 2011, and recently, Google announced first-class support for Kotlin on Android. It's being gradually adopted by well-known companies, and not only for their Android apps (examples here and here).

In addition to its modern features, Kotlin is an open-source language, and it's backed by a company that produces one the best Java IDEs.

So if you ask me, yes, Kotlin looks like a good candidate to replace Java in a (distant) future.

But let's go beyond that.

Of course, Java will be replaced by one or more languages.

Which one(s)?

I'm not sure, and I don't know if anyone has the answer to that question at this time.

What I'm sure is that no language can kill Java by itself. Nothing external, for that matter.

What will kill Java will be the inability to keep up with the demands of the market.

Programming languages are tools to build applications that solve problems with computers. If language X provides abstractions, models, tools, or frameworks that allow you to be more productive or create more efficient code when compared to Java, which one will you choose?

Even between Java versions, if you were given the choice between Java 1.4 and Java 9, would you choose Java 1.4? Would you miss the opportunity to work with lambdas or generics, among other things? I don't think so. You'll need the features of the newer versions.

During all these years, Java has earned the reputation of being a verbose, clunky language for things like checked exceptions, inner classes, getters and setters, etc. It wasn't until Java 7 (some would say Java 8) that things started to get better.

However, Java 7 was released in 2011, nine years later than Java 1.4 (released in 2002). In this age, that's unacceptable, and it can lead to a vicious circle.

Look closely at the graph on the TIOBE page for Java. Although Java has been mostly in the top-three, there's a clear downward trend that shows it's losing market share. This trend is general across all languages. The most likely reasons are that the number of programming languages is growing and that applications are being written in multiple languages. As a consequence, the competition is stronger than ever.

If a language loses its popularity because others are perceived as better, people won't teach that language to new generations of developers.

Tutorials, courses, and books won't be created.

Valuable members of the community will be attracted by other technologies.

The language won't be used in new environments.

This will contribute to decreasing the language popularity even more.

The new six-month release train proposed by Mark Reinhold, chief architect of the Java platform group at Oracle is a big step towards moving Java forward and faster and preventing that future. In his own words (referring to feature-driven releases):

This approach made it possible to deliver big new features at a high level of quality, after thorough review and testing by early adopters. The downside, however, was that smaller API, language, and JVM features could only be delivered when the big features were ready.

This was an acceptable tradeoff in the decades before and after the turn of the century, when Java competed with just a few platforms which evolved at a similar stately pace. Nowadays, however, Java competes with many platforms which evolve at a more rapid pace.

There's a lot of truth in that last paragraph.

But it's not just Oracle's job. The community has to protect Java, too.

How?

Here are some ideas:

  • Not being arrogant (by not thinking Java is too big to fail)

  • Promoting good development practices

  • Keep releasing awesome frameworks, tools, etc.

  • Supporting JSRs

  • Helping teach and promote the language

  • Trying Java in new environments

Otherwise, Java won't be able to keep up, and eventually, it will start to die.

Build vs Buy a Data Quality Solution: Which is Best for You? Maintaining high quality data is essential for operational efficiency, meaningful analytics and good long-term customer relationships. But, when dealing with multiple sources of data, data quality becomes complex, so you need to know when you should build a custom data quality tools effort over canned solutions. Download our whitepaper for more insights into a hybrid approach.

Topics:
java ,kotlin ,tiobe

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}