Students of history may recall the predictions of Thomas Malthus, who wrote that mankind's upward trend in population could no longer be supported by the agricultural system that itself supports the masses of men and women that form civilization, and that a swing the other way, typically attributed to be a major plague or other natural disaster, was imminent and unavoidable. "Population," he wrote, "when unchecked, increases in a geometrical ratio. Subsistence increases only in an arithmetical ratio. A slight acquaintance with numbers will show the immensity of the first power in comparison of the second. This implies a strong and constantly operating check on population from the difficulty of subsistence. This difficulty must fall somewhere and must necessarily be severely felt by a large portion of mankind."
Thomas Malthus published his "Essay on the Principle of Population" (see Resources) in June 1798. We have been waiting for his "Malthusian check" on population growth ever since.
Students of programming, particularly those who use the Java platform and language, may have noticed, with a growing sense of unease, the predictions and statistics that imply the imminent and evident demise of their platform of choice. Numerous candidate replacements have been nominated: .NET, Ruby, even Python, have all been suggested as the "Next Big Thing."
The parallels between these two "Malthusian checks" are striking.
Malthus postulated that because food is necessary to our existence, that the earth can produce only so much, and that our biological imperative to reproduce is constant, we will reach a point where the earth can no longer sustain the population. In other words, if we keep going the way we're going, we're doomed. Back in 1798, the logic was hard to refute.
Likewise, over the last eighteen months or so, a new trend in the Java community has emerged: predicting the death of the Java platform. From yellow journalistic articles calling it a technology of the 90's, to bombastic technical speakers evangelizing the language du jour, to books whose authors claim being "beyond" Java, the point is hard to miss: by reasoned implication, code demos, applied logic, or statistical justification, Java is on it's way out.
What Malthus missed was the Industrial Revolution, just then breaking on the horizon. Within his lifetime, Malthus was able to witness incredible surges in mankind's agricultural productivity, thanks to inventions like the steam engine and the cotton gin. Such devices thus provided the necessary "missing link" to his logic, the required multiplier to the production of food that enabled the agrarian system to stay ahead of the "passion between the sexes" that produced heavier population weight. Later, further technological innovation, this time in birth control, provided an equal downsizing factor on population growth to also ease the burden, such that now many Western nations have a negative population growth, in complete contrast to Malthus' perfectly reasonable logic. All of this, unforeseeable to Malthus as the time of his Essay, permits mankind to survive well beyond the levels at which he presumed the agrarian system would break down and cause the necessary backswing toward mere survival.
What the technology pundits missed was the rise of alternative languages for the Java virtual machine breaking on the horizon. But don't just take my word for it, let's take a walk through the arguments and see where they take us.
Some cite the statistical "passage" of Java down from its top-tier spot in programmer usage as a clear sign that Java's demise is under way. Others point out the lack of particular features, provided by alternative environments, features which are "demanded" by customers and their application requirements. Still others point to (undefended) statements like "BigCorporation doesn't use Java," thus providing a clear implication that if BigCorporation doesn't use it, it must be because that technology is not worth using.
The Java language, and to a much greater degree, the Java platform and its associated ecosystem, have long since passed what Simon Peyton-Jones refers to as "The Threshold of Immortality," just as C++, C, COBOL and other languages have done. These are tools that will be in existence nearly forever, either because they continue to serve a useful purpose or because the costs of attempting to rewrite that code simply dwarf the costs of continuing to use and maintain those systems "as-is." (Whether a particular language or system falls into the first category or the second is a matter of much debate, and, for our purposes here, is largely immaterial.)
Another argument has all of the smart people leaving Java and going to (platform X) or (language Y). In a 2005 BusinessWeek article, "Java? It's So Nineties" (see Resources), cites Peter Yared, former CTO of long-since-defunct app server company NetDynamics, as saying, "Java is a dinosaur." And yet, without even blinking an eye at the conflict of interest and syllogist logic, the article notes that Yared owns a company looking to re-create the app server experience on top of the LAMP (Linux®/Apache/MySQL/P-language) stack.
(It would be cheeky to point out that Ruby's date of conception actually predates Java's, as does Perl's and Python's, not to mention Linux's, Apache's, and MySQL's ... so I won't.)
To quote a favorite movie, "Life is pain, Highness. Anyone who says differently is selling something." Or, to paraphrase more apropos to the subject at hand, "Transitioning to a new platform is pain, Mr. CTO. Anyone who says differently is selling something." And, perhaps not surprisingly, in the case of some of those Java experts who've relocated to different technology regions, this is precisely the case.
Consider the argument that states, "Java's fallen from its position as top language in the world. Therefore, the decline must be catastrophic, and I'd best get out of the way of the avalanche." This argument rests on the basic premise that if Java is not the absolute number one best-selling technology in the world, it must not be worth supporting. Which, when examined in the cold light of logic, doesn't make a great deal of sense, on two fronts.
One, the process of using statistics has long been shown to be of questionable use when used carelessly, as Benjamin Disraeli so aptly noted when he said, "There are three kinds of lies in the world: lies, damned lies, and statistics." Statistics can be used to prove even the most fallacious argument, simply by carefully selecting which statistics one cites as part of the argument. Note carefully the citations used in the BusinessWeek article: "Reports ... show Java use is slipping as LAMP and Microsoft®'s .NET technology gain traction." Wow, that sounds bad. Keep reading, though. "In North America, the percentage of developers who use Java as one of their principal programming languages declined to 47.9 in Evans' fall survey, vs. 51.4% in the fall of 2002." So, over six years, usage has fallen three and a half percentage points, among those developers who use Java as one of their principal programming languages.
Note carefully that the phrase is "principal" programming language, meaning the developer himself was forced to make a distinction as to what is their "principal" language. A developer using the Spring/Hibernate/JSP Java stack may very well imagine that Java is no longer their principal language, considering the massive amount of XML configuration said stack implies.
Note as well the rise of dynamic languages on the Java platform (Jython, JRuby, Groovy, even JavaFX) over the last six years, which easily accounts for the drop in three percentage points, based on the adoption numbers I and my fellow "No Fluff Just Stuff "speakers are seeing in our informal polls at NFJS events.
Or consider another quote from the same article: "In a different survey series, the use of PHP in North America grew to 36.1% this fall, from 26% in the fall of 2003. It grew almost as quickly in Europe and Asia." Given that this is a "different survey series," it serves only to show that PHP is growing, not that Java is shrinking. Congratulations to PHP, but as any developer who has spent time in a large corporate environment can attest, production software deployments are hardly the zero-sum game the article's author seeks to imply it to be. Large IT environments are frequently made up of a wide spectrum of tools, platforms, languages, and products. In fact, we could almost hope for a consolidation here, particularly when it comes to all that mainframe stuff.
In fact, speaking of mainframes, COBOL has been out of that number one spot for several decades now and yet it continues to cash checks, transfer deposits, pay credit cards, and run major financial networks, all despite having been pronounced "dead" by numerous industry pundits. Not bad for something supposedly rotting in the grave; reminds me of Mark Twain, who when shown his own obituary in a hometown paper, remarked, "Gentlemen, reports of my demise are greatly exaggerated."
Setting the issue of statistics aside, however, the second point is an even larger one: Just why is it time to turn tail and run simply because your tool of choice is not number one? Java has held the principal slot for software development for near on to a decade; now that it has "fallen" to a number two ranking, the game is over? Even accepting the presumption that inertia alone will prevent Java from ever reclaiming that top spot, the fact remains that 4 in 10 programmers continue to use this language, guaranteeing longevity for decades to come. And even accepting the (rather ridiculous) presumption that Java's growth comes to a screeching halt and not one more Java deployment ever occurs, Java's current widespread deployment throughout the industry guarantees Java presence for at least that same length of time.
Just ask the COBOL guy making six or seven digits a year about working with a "dead" language.
Pointing out the flaws in an argument doesn't prove a point, however, and the same is true here; instead, a critical eye needs be cast upon the Java language and platform, and its strengths and weaknesses held up for unflinching analysis. Java's survival lies in its ability to meet the challenges of the coming decade, not any author's or pundit's pronunciation of its life or death.
To that end, let's consider the constituent parts that make up the Java platform:
The Java programming language. Frankly, this is the part of the
platform that most shows its age, particularly when compared against more
"modern" languages like C#, Groovy, (j)Ruby, or Scala. The flood of recent
suggestions on how to improve the language, such as the competing
proposals to add closures to the language, demonstrate how deeply Java
programmers desire the "missing pieces" they see in other
languages. However, the mixed success that came with the last batch of
language enhancements in Java 5 should act as a cautionary brake on
any new major language changes. Certain enhancements, such as the enhanced
forloop or annotations, met with (relatively) widespread acceptance, while others, such as generics, met with (relatively) widespread derision and criticism. The fact that none of those language features met with universal acceptance from the developer community they were supposed to help, however, is telling: Adding new language features to a language more than a decade old is a tricky business, and possibly one that, if done again, could cause the language to collapse under its own weight. On the map of the Java platform, this area is marked with the ancient mariner's warning: "Here there be Dragons."
Non-Java JVM programming languages. Where Java leaves off, other
languages pick up, enhance, and provide solutions. Groovy provides a nice
dynamic, objectish scripting solution around Java objects. (j)Ruby offers
a Ruby implementation on top of the JVM, opening up the world of Rails and
ActiveRecord to Java programmers. Scala and Jaskell bring functional concepts
home to the JVM, offering potential solutions to the rising problem of
concurrency. And so on, and so on, and so on. And because all of these
languages either compile to bytecode or run on top of the JVM as an
interpreted language through the javax.script API, the entire wealth of
the Java ecosystem is still available — something that Rubyists cannot
claim in return. On the map of the Java platform, this area is marked as
"The Land of Opportunity."
The Java virtual machine. Fortunately, where the Java language
has seen significant calls for revision and radical change, the underlying
foundation of the Java platform, the JVM, has seen relatively little. Of
late, some suggestions for making the JVM friendlier to dynamic languages
have come through the blogosphere, leading a Sun engineer (John Rose) to
offer up a revised version of the JVM, first known as the Multi-language
virtual machine (MLVM), now renamed the Da Vinci Machine (because it is
so tightly wrapped up in code). The key here will be for the
proposed JVM changes to avoid anything that might invalidate the huge
investment Sun has made in the JVM's optimizations. From what discussion has been taking place on the subject of
JVM enhancements, those who are making the suggestions are keeping that
very clearly in mind as they work out the details.
The Java Standard Edition libraries. Java Standard Edition
ships with an enormous set of functionality, orders of magnitude larger
than the C++ standard library, even several factors larger than itself
back in the Java 1.0 days, and this doesn't even consider the Enterprise
Edition libraries (discussed next). On the surface, this seems like a
natural win for the Java developer, but a few subtle problems appear after
some reflection. The sheer size of the libraries, for starters, means that
many Java developers do not realize that they are writing code that actually
already exists, tucked away in a heretofore unknown package. The libraries
themselves, depending on their age, sometimes also suffer from the advancing
age of API design, many of them hailing from the mid-90's, when developers
designed classes and libraries very differently from how we do in
2008. Some of them also fall prey to an overabundance of abstraction,
as exemplified by factories that create object builders that create
instances of interfaces that may or may not implement the methods of
interest to the developer. Still, for all the warts in the JSE library, on the whole, JSE represents a net gain,
particularly when combined with language-supported enhancements like the
extensions Groovy provides to the JDK (called the GDK).
The Java Enterprise Edition libraries. No technology has taken
a larger beating at the hands of its community than EJB, and fortunately
the Java community has seen the rise of lightweight alternatives, as best
exemplified by Spring and Hibernate, for those scenarios where a
lightweight alternative is the right choice. Excepting EJB from the
discussion for a moment, however, the Java EE libraries
have turned out to be phenomenally successful — servlets and servlet
containers power a significant portion of the Web applications throughout
the Internet and corporate intranets, JMS provides access to a variety of
different message-oriented middleware systems, and the other,
less-recognized, players in the JEE space, such as JNDI, carry out their
assigned tasks with little complaint. While the JEE libraries could
probably benefit from an API redesign just as the JSE libraries could, on
the whole the JEE libraries serve the needs of the Java programmer; the
largest problem is often knowing when those needs actually demand the
JEE libraries in the first place. But that discussion is for another day.
The Java-API-for-XML (JAX) libraries. Although nominally a
part of the JEE library set, the JAX APIs have been
growing in number and size at a rate disproportional to the rest of JEE
and are probably worth examining outside of the JEE context.
Although the demand for XML support was huge and widespread in the early
part of this decade, that demand has softened somewhat, particularly around
the area of Web services (WS-*) and its horde of specifications that
promised ubiquitous and easy interoperability with other technology
stacks, most notably .NET. Here Java clearly needs some kind of revamp,
as the SAX, DOM and StAX APIs often require much larger amounts of code
to perform nontrivial tasks, particularly when compared against languages
with more flexible XML support, such as E4X, Ruby or Scala. Here, too,
the thinking around XML has changed significantly, from the "Keep the
XML out of sight" in early WS-* implementations, to the "I want to touch the XML and address it to well-formed and meaningful
URIs" of RESTful-based approaches, which also underscores the need for
a JAX-wide refactoring. On the map of the Java world, this is the area
marked "(Should Be) Deprecated."
Java on the client. Sun's recent beta release of the revamped
"Java client" system, under the rather awkward name of "Java SE 6 Update
10 Beta," offers enhanced client-side features, including a new Swing
look-and-feel, called Nimbus. Unfortunately, measuring Java's usage on
the client side has always been problematic, largely because for a long
time this meant measuring applets in use across the Internet, and because
so much of the design and architecture focus of Web-hosted applications
was around generating HTML, not producing what are now called "rich client"
applications. As adoption rates go, Java has a long way to go here to
catch up to its principal competitor in this space, Flash, and the
introduction of Microsoft's new player in the game, Silverlight, doesn't
make things any easier. Java may well lose this ground entirely, which,
while not representing the "death" of the platform, will exacerbate the
problem, as industry pundits and trade magazines leap on this "obvious
example of Java's technical weaknesses." Brace yourself.
Java on the server. This really needs no defense: Java is,
without a doubt, the established player in the server space, particularly
when examining the options for non-Windows® back-end farms. LAMP stacks
might offer a front-end or vertical silo alternative, as does Ruby on
Rails, but when looking at serious server computing infrastructure,
the Java stacks figure prominently. In fact, this established dominance
is what led Microsoft to aggressively pursue the WS-* specifications in
the first place, so that .NET code could at least call into, and work
well with, the established Java infrastructure. Microsoft's recent nods
toward interoperability at a more formal level, including their
"Interoperability Lab" in Cambridge, only underscore this point.
- The ecosystem. No other platform has as rich and varied an ecosystem as the Java platform, and while this frequently leads to some heartache for the Java developer ("Which Web framework should I use?"), the fact remains that much of the Java ecosystem leaks over into other environments, particularly that of .NET. Consider the most recent advancements in the .NET platform coming from both outside and inside of Microsoft: ObjectBuilder (a dependency injection framework), ASP MVC (an MVC-based Web framework), NHibernate (a part of Hibernate), NAnt and MSBuild (XML-based build systems similar in syntax or concept to Ant), and even Silverlight itself (hosting the CLR inside the browser to permit richer client-side execution). In many ways, the .NET ecosystem stands about five years behind that of the Java community, as .NET developers discover the same pain points Java developers faced five years prior. While Java still stands to learn from the .NET community as well (such as the usefulness of a unified communication API, or the power of an explicit lightweight workflow engine), this only serves to underscore the fact that both environments are learning from each other, and that .NET doesn't have what it will take to make Java unnecessary.
Undoubtedly, Java developers will have their own items to add to this list, but the point, hopefully, has been made: There's too much goodness left in the Java platform to call it "dead," or "dying," or even "marginally under the weather."
The simple fact remains, then: Java, the platform, the ecosystem, the environment and the development community, stands at least as far from the Abyss of Irrelevancy as any of the other languages or platforms currently in use today. Even the most aggressive statistical filtration of facts cannot push Java from the top of the heap.
What's more, even if Sun Microsystems were to disappear tomorrow, this is not a platform-killer. Java developers, unite! You have nothing to fear from the chains that bind you: it turns out those chains don't really exist. Thanks to the open-sourcing of the Java platform, now called the OpenJDK, not to mention the other open-source "clean room" implementations of Java (Apache Harmony and Soy Latte being just two), even if should Sun disintegrate and disappear off the map entirely, other entities, including IBM®, Apache, BEA and Oracle, can continue to offer the JVM, libraries, and tools to support the ecosystem as a whole.
Will Java die someday? Absolutely, but I strongly suspect that it will outlive a good portion of the current population of programmers currently using it, just as COBOL has done. It may even outlast the second generation of Java programmers just now coming out of universities and colleges.
- Read the "Essay on the Principle of
- Check out the article "Java?
It's So Nineties" (BusinessWeek, December 2005).
Java, still hot or losing its flavor? (developerWorks. May 2008): The author and fellow developerWorks contributor Scott Davis discuss the longevity of the Java platform.
Browse the technology bookstore for books on these and other technical topics.
developerWorks Java technology zone: Find hundreds of articles about every aspect of Java programming.
Get products and technologies
- Download Java 6 from Sun Microsystems.
kits for the Java platform: The IBM Centre for Java Technology Development provides Developer Kits for creating and testing Java 2 Platform, Standard Edition applets and applications on some of IBM's most popular platforms.
- Download and install the OpenJDK.
- Download Apache Harmony.