TechRepublic recently published an article about languages that developers love and those that they hate. This produced an interesting set of results since Java was the third most loved language as well as the second most hated. Clearly, Java, as a language, polarises opinion. When I tweeted about this, I got one reply which quoted Bjarne Stroustrup, the creator of C++, “There are only two kinds of languages: the ones people complain about and the ones nobody uses.” I think he has a point.
A second article from Packt Publishing about their Developer Survey also highlighted, superficially at least, Java in a negative way. From their results, Java came top as the tool most developers regretted learning. It’s worth putting this into context, as the data shows that, even though Java came first, less than 5% of respondents gave this answer. It’s not clear what that is 5% of: the total number who took the survey (which would be 226 developers), those who had some regret (102) or those who put Java as their primary language (38). Whichever way, I don’t think it shows a significant trend for developers. Some of the reasons cited for this regret are the ones we have heard for many years already, “Java seems to be getting phased out”, “It has become the COBOL of modern programming” and “The code is very long and complex. It’s so hard to learn”.
The authors of this report make a rather bold claim about the reason for this result:
“The uncertainty around Java has certainly been exacerbated by Oracle’s decision to focus on enterprise Java and withdrawing support for OpenJDK. Although Red Hat’s takeover means there is a future for Java, there are undoubtedly warning signs for people that have been relying the language for some time.”
Note, you will need to download the full survey results to see this.
Unfortunately, almost everything in this statement is wrong. Oracle has most definitely not withdrawn support for Java. True, they have changed how the Oracle JDK is made available, but you can still download and use the Oracle OpenJDK JDK without charge. There are several providers (including Azul) making older versions of the JDK available with updates either free or with paid commercial support. Red Hat, whilst an extremely strong supporter of the OpenJDK, has not taken over. Andrew Haley, who works for Red Hat, is now the project lead for OpenJDK 7, 8 and 11. Oracle still leads the OpenJDK project for the current release.
Even after 24 years, Java continues to be either at the top or very close to the top of surveys that rank the popularity of programming languages (things like the TIOBE index and the RedMonk Programming Language Rankings). Over the years we’ve seen several languages quickly rise in popularity, leading to claims that they will soon replace Java. Prominent examples I can think of are Ruby on Rails (technically a framework rather than just a language), Scala and, most recently, Kotlin.
This leads me to something I was thinking about recently, which was how difficult it is for those who steward the Java platform; people like Mark Reinhold, Brian Goetz and John Rose. In this case, to quote John Lydgate, a 14th Century Monk, “You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.” (Really, we should apply the vi command, :/people/developers/g to this).
James Gosling, the Father of Java, described it as a Blue collar programming language. The fundamental idea was to provide a language that let developers get the job done. In this it has been remarkably successful.
The hard part is how to evolve the platform. How do you change Java to simplify it to make some developers happy without upsetting those that like the core syntax the way it is?
Let’s return to the last quote from the Packt Developer Survey, “The code is very long and complex. It’s so hard to learn”. This is a common criticism of Java that there is too much boilerplate code; it’s too verbose.
Over the last two decades, we’ve seen a number of changes to, if not solve, then at least mitigate this issue. The introduction of annotations in JDK 5 has made enterprise Java development a whole lot simpler by allowing things like dependency injection. I doubt anyone develops web services today without using annotations. Lambda expressions and the streams API in JDK 8 have made processing collections of data a lot more concise. Even changes like Project Coin have helped in small ways (multi-catch and try-with-resources are good examples).
Compared to a language like Kotlin, Java is still verbose. The significant advantage that the Kotlin developers had when they started was they did not need to maintain backwards compatibility with decades of existing code and applications. This is something the OpenJDK developers have taken very seriously.
From a personal perspective, one of the most powerful features of Java as a development language is its readability. I think most developers will agree that code is more frequently read than written. All developers, at some time, will have to maintain someone else’s code. The easier it is to understand, the easier it is to address bugs or make enhancements. I once had to work on an application that had been written in Perl. It wasn’t that big an application, about eight-pages printed out, but I rapidly concluded that Perl, with its incredibly dense syntax, was a write-only language. Verbosity is not always a bad thing!
What’s really important is that Java is continuing to evolve. With the new six-month release cadence of the OpenJDK, it might seem like the pace of change has slowed but, if anything, the reverse is true. We are seeing a constant stream of new features, many of them quite small, yet making developers lives much easier.
To add big new features to Java takes time because it’s essential to get these things right. We will see in JDK 13 a change to the switch expression, which was introduced as a preview feature in JDK 12. Rather than setting the syntax in stone (via the Java SE specification), preview features allow developers to try a feature and provide feedback before it is finalised. That’s precisely what happened in this case.
The longer-term Project Amber will continue to make well-reasoned changes to the language syntax to smooth some of the rough-edges that developers find trying at times. You can expect to see more parts of Amber delivered over the next few releases.
The good news is that love it or hate it, I think Java will only continue to get better thanks to the hard work of the OpenJDK architects. This will help it to remain one of the most popular development platforms on the planet.
