No matter what ranking system you look at, whether the TIOBE Index, the Popularity of Programming Language Index, RedMonk’s bi-annual language rankings, or GitHub’s yearly State of the Octoverse, Java has been sitting among the top three languages since shortly after its launch in 1995. To listen to the general scuttlebutt of the developer crowd over time, however, you might think that Java was in fact in a period of great decline, or even on its deathbed. Take a closer look at some of these popularity numbers and you might argue that Java has slowly given up market share to its linguistic competitors, another obvious sign of its impending demise. Some proponents may argue that there are simply more languages arriving all the time—as such, the pie gets bigger and the pieces get smaller. Still: Impressions matter.
While Java may have hit some hiccups earlier in its life, nowadays the language and its greater ecosystem have picked up the pace to meet the needs of the future in a variety of ways. In fact, it never really went anywhere: Companies like Amazon, Google, Netflix, Pinterest, Spotify, Square, and Zoom all employ Java across their vast codebases. Not to mention much of the high-scale data infrastructure over the past decade has been powered by Java, with the language serving as the backbone for the likes of Apache Hadoop, Kafka, and Spark. Declare it dead again all you like, but what we see now with Java is a bit of a revival; a rejuvenation of the language for those future use cases it was recently prudent to argue that it could not meet.
That is, Java could be described in the immortal words of LL Cool J: “Don’t call it a comeback, I been here for years // I’m rockin’ my peers, putting suckers in fear.”
Java’s years of discontent
In just two years Java ranked number three in popularity, outpaced only by C and C++. By 1998, it surpassed C++, and in 2001 it overtook C for the number one spot. Within the span of six years, Java took over the world of software development. And while that position would hold for well over a decade, not all was copacetic in the world of Java.
Andrich van Wyk, Chief Solutions Architect at EPI-USE Labs, recalls a time when development of the Java Programming Language (JPL) was stagnant and seemingly in question, despite its dominance. The low point came around 2009, he said, when Java 6 had already been around for nearly three years, and yet Java 7 remained two years off in the distance. When Java 7 finally did arrive, van Wyk recalls it being “a relatively mediocre release for five years of development,” characterizing the time as one where “developers were hungry for more modern language features, less verbose code, and new programming paradigms.”
Evidence of these desires was all around: The Rails framework for Ruby was at perhaps the peak of its initial hype cycle, while Node.js had just appeared, and both exemplified features such as code brevity, rapid prototyping, and libraries for quickly building modern web applications. In other words, they were many of the things that Java was not, at least at that time.
“All of these things would later be available in Java with modern releases and frameworks like Spring Boot, but we had to wait until 2014 and the release of Java 8 for that renaissance to kick off,” recalls van Wyk. “The almost decade between Java 6 and 8 was the problem.”
If there were ever a time during which Java’s near declaration of death could be made, it was then. Lucky for Java, companies and developers had gone all in on Java and it was entrenched in many organizations. Even if many of its users were growing increasingly dissatisfied and innovation in the language had stagnated, Java still offered performance alongside a slew of libraries and tooling. Maybe it never fully lived up to the “write once, run anywhere” promise, but it offers a highly performant, memory-safe language ideal for internet infrastructure and large-scale applications.
Still, the launch of Java 8 and Spring Boot in 2014 brought a breath of fresh air to the Java ecosystem and kicked off a period of rejuvenation. Spring Boot, the successor to the popular Spring framework introduced a decade earlier, helped finally reduce some of the verbosity Java was known for and Java 8 introduced many features that developers had been anxiously awaiting, such as the date and time API and the much-anticipated arrival of Lambda expressions.
While van Wyk points to 2014 as a major turning point for Java, Mike Milinkovich, executive director of the Eclipse Foundation, notes two other moments as key. First and foremost, the release cadence for Java changed in 2018 with the release of Java SE 10, ensuring that a new version of Java would be made available every six months, rather than the often years-long timeframe that preceded it.
“Java is now competing with many platforms that evolve at a fast pace,” says Oracle product manager Dalibor Topić. “Therefore, it also had to start to move ahead faster, minimizing the pain of waiting for new releases for Java users and developers while delivering each new Java release at the accustomed high level of quality.”
“Java really hit its stride with Java 9 and the increased release cadence around 2018,” he says. “The smaller but much more frequent releases are really working well.”
At the same time, Milinkovich points to a change with the Oracle Java Development Kit (JDK) that shook things up for Java developers and companies running Java applications in production or for commercial purposes. First announced in 2017 and taking effect in April 2019, Oracle required those users to purchase an annual subscription to continue receiving security patches for Oracle’s Java Platform, Standard Edition (Java SE) products, Oracle JDK 8 and 11. “For years and years, long-term support of Java was effectively free. As an enterprise, you could run your applications on Java, and not have to move versions forward frequently. That status quo was changed, forcing Java users to either migrate every six months or seek a commercial support license from Oracle or others,” explains Milinkovich.
Rather than hindering innovation, the Java ecosystem flourished. The change spurred numerous cloud providers, such as Amazon, Microsoft, IBM, Alibaba Cloud, and Huawei, to offer their own Technology Compatibility Kit (TCK)-tested and supported versions of OpenJDK in response. The first of those responses came with the release of AdoptOpenJDK by the London Java User Group.
Martijn Verburg, leader of the London Java User Group, says the group first released AdoptOpenJDK because they were unsure about the usage rights developers had under Oracle’s changes around OpenJDK. “They wanted to ensure there was a Free (as in beer) and Free (as in use) OpenJDK binary for developers in perpetuity,” says Verburg. AdoptOpenJDK was a “multi-stakeholder project,” explains Verburg, that eventually “moved to the Eclipse Foundation (as Adoptium) to enshrine that access to a free binary (Temurin) at a software foundation.”
The OpenJDK changes, says Milinkovich, “encouraged multiple companies to enter the game of being-their-own Java platform provider. The growth in the number of vendors in the ecosystem has been helpful for the diversity and sustainability of Java, because many parties were forced to invest in producing high-quality Java runtimes than they would have otherwise done.”
A boost from the JVM ecosystem
Looking back in time again, we can also point to Kotlin and Scala, two languages that operate on the Java Virtual Machine (JVM), as participants in Java’s so-called revival. The JVM runs any Java bytecode, a key part of Java’s “write once, run anywhere” promise. Both Scala and Kotlin are specifically designed to be compiled into Java bytecode and run on the JVM. Scala first appeared in 2004, just before Java’s lurch in innovation, and Kotlin arrived in 2011, quite in the middle of that same period.
Kotlin and Scala could take advantage of the JVM’s stability and ubiquity, while also enjoying the freedom to do things that Java simply couldn’t risk. At the same time, any risk that panned out for either language could serve as proof positive that the feature operates as intended on the JVM and doesn’t bring systems crashing down. For Java developers, other languages on the JVM offer Java-compatibility while perhaps simultaneously addressing their concerns about Java’s deficits. Languages like Kotlin and Scala are not only standalone languages with their own benefits and use cases, but they provide a way for developers to familiarize themselves with concepts foreign to Java that may ultimately bubble their way up into the JPL.
“Having other languages on the JVM has been a really good way to see which novel ideas can get traction in their respective communities, without having to experiment with embedding them in Java right away,” Topić says. “Instead, we can pick the winning ideas and work in the open with collaborators in academia, industry, and other open source projects to gradually adjust and refine such ideas to make them fit really well within Java itself, surfacing them as language and library features that end up feeling ‘native’ to Java.”
“We often talk about Kotlin as a production playground,” says Christina Lee, a team lead and software engineer at Pinterest. “Kotlin doesn’t have as much legacy as a lot of the JVM use cases, so they can move really fast on their language. That’s just not something that you have the option to do in Java. These offshoot languages are giving us the ability to try all these features very quickly and then the best of those can be upstreamed back into the Java programming language.”
Lee points to new Java features like records and field classes, which Kotlin has had equivalents to for some time. Van Wyk similarly points to pattern matching as a language feature that he’s familiar with from Kotlin that has made its way into Java. “It’s the last mover advantage,” says van Wyk. “It’s because Java is the last one to implement these features that it can pick and choose what it wants in a way that brings developers what they need without them shooting themselves in the foot.”
Van Wyk points to Scala as the language that helped him learn functional programming initially, and gave him a foot up. “Java 8 came along and it had functional programming, and I was like ‘Hey, I know how to use this already!’” he says. Similarly, Kotlin helped introduce him to coroutine support, a feature popularized by the Go programming language. “If not for Kotlin, some of the upcoming Java features would be more puzzling,” says van Wyk.
In 2017, Google announced that it would officially support Kotlin on Android, alongside Java, and the language has bloomed in popularity ever since. Lee says that Kotlin has since been her language of choice and that she has no plans on turning back, especially as Google itself declared all its own Android development would be “Kotlin-first” starting in 2019.
For Lee, Kotlin offers a way to develop for Android that avoids some of Java’s pitfalls, which are particularly perilous when it comes to developing for mobile. For example, a NullPointerException is a common error when writing Java that can crash an application, but can’t necessarily be found until runtime. This is problematic for mobile development, says Lee, because unlike a web application, where bug fixes are instantly available to customers once deployed, it can take days or weeks for an app store to approve new versions. “I value safety in a language much more highly than I would if I was working in another ecosystem,” says Lee. “Java is a great language, but it doesn't give us the same tools to write correct code as these layers on top of the JVM, like Kotlin.”
Rather than looking at Kotlin and Java as a zero-sum game, where an increase in popularity of one means a decrease of the other, Lee says she sees the languages as existing in symbiosis. After all, they can literally coexist side-by-side in the same application. In fact, for Java developers who are interested in learning Kotlin, they can simply write something in Java, paste it into a Kotlin file, and it can be automatically translated into Kotlin by their IDE. “That’s part of why Kotlin is so successful, in my opinion,” says Lee. “There is that transferability.”
Lee offers the comparison of Apple’s choice to move to Swift from Objective C, where it requires additional steps to communicate between the two languages. “They don’t have that interoperability story. It’s so much harder to move iOS apps to Swift. At Pinterest, when we first introduced Kotlin, you could just add a Kotlin file and everything works. You can easily call between the files, and that opens a huge pathway to adoption that would not be nearly so easy otherwise. I think the fact that these languages play so well together makes them very, very cohesive,” Lee says.
Kotlin, she says, offers a perfect middle ground. “You can keep all of your existing infrastructure and address some of those user experience pain points without throwing the baby out with the bathwater. There's less and less reason to fully move away from the JVM.”
Java vaults itself not-so-slow and steady into the future
After nearly 30 years of Java, you might expect the language to be showing some signs of wear and tear, but nothing could be further from the truth. Java in 2022 is not a language in decline, but rather a language preparing for the effervescent future of software development. When Java finally began innovating again in the mid-2010s, there was already the shadow of cloud native development looming overhead, and now it is increasingly the default, especially for enterprises and software running at scale. While other languages such as Go are seen as designed with the cloud in mind, Java is often thought of as bulky, says Ryan Morgan, vice president of software engineering at VMware.
“There has always been a shadow over Java, people think ‘It's bloated, it's heavyweight, it's not cloud native, it's not built for the cloud, it doesn't allow for a density that you might want out in the public cloud’,” says Morgan. “A lot of work has been done to really dispel those myths.”
For its part, VMware is working to improve Java’s cloud nativeness with the upcoming release of Spring Framework 6 and Spring Boot 3, which Morgan calls Spring’s “act three.” Spring, built with GraalVM, will provide “full native support within Spring, meaning that you’ll be able to take any Spring application and compile it down into a native binary with a smaller footprint and startup time. It will be really beneficial for all kinds of other workloads that you might see out on the edge.”
Spring is not alone in this effort. Both Red Hat’s Quarkus and the Micronaut project are helping to propel Java into that one realm some previously thought not possible for Java: out onto the edge and into microservice architectures, places where small size and fast start-up time can be key. Similarly, Project Loom aims to bring lightweight threads to the Java platform by implementing threading in the JVM, rather than the operating system kernel. “This represents a significant improvement in Java’s ability to support concurrency, making the platform more relevant for many of today’s cloud-scale applications,” says Milinkovich. “With Project Loom, writing highly concurrent applications in Java is going to become simpler for developers and much more scalable than today.”
For Milinkovich, it’s precisely projects like Quarkus, Micronaut, Loom, and Adoptium that he sees bringing Java into the next generation of developers.
“Java has been around now for 25 years and I believe that it’s going to be around for another 25 years. I think it’s undergoing a renaissance, both from a technology perspective, but just as importantly from an ecosystem perspective,” says Milinkovich. “One of the things for developers to keep in mind is that Java skills are in high, high demand. That’s really going to help attract continuing support from developers, and I think you’ll see that Java is going to remain in the top three of loved languages and platforms for the foreseeable future.”