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.

Malthusian predictions on Java

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.

Back to top

Examining the evidence

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 for loop 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."

Back to top

I'll be back

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.

"Dinosaur," indeed.

Resources

Learn

• Read the "Essay on the Principle of Population."
  
  
• Check out the article "Java? It's So Nineties" (BusinessWeek, December 2005).
  
  
• Podcast: 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.
  
  
• IBM developer 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.
  
  

Discuss

• Check out developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Ted Neward is the principal of Neward & Associates, where he consults, mentors, teaches, and presents on Java, .NET, XML Services, and other platforms. He resides near Seattle, Washington.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Malthusian predictions on Java
• Examining the evidence
• I'll be back
• Resources
• About the author
• Comments

Next steps from IBM

Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
• Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
• Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
• Buy: WebSphere Application Server - Express

My developerWorks community

Dig deeper into Java on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers