For the record: Java is not dead, nor is it dying. It is, however, mature, and perhaps a little grumpy and set in its ways.
Yet it seems one of the best ways to draw attention to a post or commentary on Java and programming is to use the Words Java and some variation of dead in the headline.
For instance, recently Mark Little, senior director of engineering at Red Hat, wrote a blog post entitled: JBoss polyglot – death of Java?“
And although the headline suggests that Red Hats JBoss unit is pushing a polyglot programming strategy of using several languages for different projects, the gist of the post is that the company is not trying to move away from Java. In fact, Little makes it plain that we’re as committed to Java today as we’ve ever been.
Little noted that JBoss is doing projects with languages such as Ruby, Scala, C/C++, Erlang and others. In the post, he said:
“¦ you can’t fail to have noticed that we’re doing quite a bit of work with languages other than Java. Those include Ruby, via TorqueBox, Clojure with Immutant, C/C++ in Blacktie, Scala in Infinispan, Ceylon and my own personal favorite Erlang. (OK, that’s still more a pet project for me than anything else.) But does this mean that we’re turning our backs on Java? No, of course it doesn’t! If anything it shows our continued commitment to Java and the JVM because all of these approaches to polyglot leverage our Java projects and platforms.“
Little added that some of the efforts Red Hat has been involved in that stress its commitment to Java include: Putting JBossAS 7 onto OpenShift; various discussions and presentations on how core enterprise capabilities transcend languages and Java is a great solution; JBossEverywhere is all about making JBoss core services and projects available on a wider range of devices and platforms, some of which are not Java-based but many of which are; the companys increased presence and adoption at JavaOne; and its efforts to define a common fabric/platform across deployments, which will be based on Java and more in line with ubiquitous computing.
Then there’s the number of times that our competitors keep telling people that Java and EE6 are dead and we keep having to set the record straight, Little said.
So Little makes no bones about acknowledging continued support for Java. Hes just saying Red Hat, like so many other companies, is using other languages. Oracle, the owner and steward of Java is even encouraging Java supporters to use other languages on the Java Virtual Machine. The Da Vinci Machine Project is an effort to extend the Jave Virtual Machine (JVM) with first-class architectural support for languages other than Java, especially dynamic languages.
There Is a Need for Multiple Languages
There are several languages supported by the JVM, including Clojure, Groovy, Scala, JRuby, Jython, Rhino and AspectJ, to name some.
“There is clearly a need for multiple languages, Mike Milinkovich, executive director of the Eclipse Foundation, told eWEEK. Mark’s post was absolutely right that the JVM is providing the platform for a renaissance of programming language development and adoption. It will, however, be interesting to watch how the JVM-polyglot scenario unfolds, as there is also a cost to projects if they try to build and maintain applications using multiple languages, even if they’re based in the same runtime architecture. I suspect it will take a while before best practices emerge.”
Essentially shrugging on the discussion, Grady Booch, chief scientist for software at IBM Research and a software and computer technology historian, quipped: A person who knows several languages is multilingual. A person who knows two languages is bilingual. A person who knows one language is an American. I know of zero projects of any interesting economic value that are not multilingual. But that doesn’t portend the death of Java.
And for his part, James Gosling, the creator of Java, candidly told eWEEK, Java, the programming language, was always something of a scam to convince C/C++ programmers this brave new world was something that they could understand. All the magic is in the JVM, and I’m thrilled by all the other languages using it, although I’ve only dabbled in them since none has really converted me. Scala came very close for a while, and I used it in a biggish project, but I ended up reverting. Scala has all sorts of built-in ideas about how to do various things like pattern matching; if it’s not quite what you want, you end up fighting. I conceptually like Clojure, particularly its use of immutability, but I exhausted my lifetime tolerance for parentheses when writing my Ph.D. thesis.
This whole thing about Java and death puts one in mind of Anne Thomas Manes 2009 post that SOA is dead, which shed light on services and was not intended to nail the coffin on service orientationwhich is still alive and well. And like the constant attempts to bury the mainframe, the rumors of Javas demise have been greatly exaggerated.
Some Say Rumors of Javas Demise Have Been Exaggerated
Like the mainframe, Java isnt going anywhere. It is the No. 1 language for enterprise development. IT organizations ask for it for major enterprise projects. There are more Java jobs around than any other. There continues to be a huge demand for Java developers, and as such there is a large base of Java developers and new folks who are learning the language. Its a stable language that enables developers to create well-structured code that is easily maintained.
There also is a host of good tools for Java. Java has a huge ecosystem and so many of the surrounding projects and products that support mobile platforms and big-time enterprise computing are Java-based: Android, Hadoop, Jenkins, Cassandra and HBase, to name a few.
Also, Javas position in January 1996 was No. 5 on the TIOBE Index of the most popular programming languages in use by developers. In January 2006, it was No. 1 and has hovered around the top ever since. The most recent TIOBE Index shows Java at No. 1, but was flat for growth.
At 17 years old, Java is certainly mature and beginning to show signs of age in that its architecture, along with the JVM, can be restrictive for some new programming paradigms. Oracle and the Java Community Process (JCP) try to address these issues with updates and changes to the Java language and platform. So despite losing a bit of its luster, the Java standard remains strong.
For instance, at the Free and Open Source Software Developers European Meeting (FOSDEM) in February 2011, Stephen OGrady, an analyst and co-founder at RedMonk, said, Java is no longer as popular; what Java is, is the most popular. OGradys FOSDEM 2011 slides can be found here.
However, in a post from November 2010, Mike Gualtieri, then a Forrester analyst, called Java a dead end. The post, entitled Java Is A Dead-End For Enterprise App Development, reads:
Java is not going away for business applications, just as COBOL is not going away. Java is still a great choice for app dev teams that have developed the architecture and expertise to develop and maintain business applications. It is also an excellent choice (along with C#) for software vendors to develop tools, utilities and platforms such as business process management (BPM), complex event processing (CEP), infrastructure as a service (IaaS), and elastic caching platforms (ECP). Software such as operating systems, databases, and console games are still mostly developed in C++.
Gualtieri, who is now a vice president of marketing at Progress Software, also said in that 2010 post:
Java development is too complex for business application development. Enterprise application development teams should plan their escape from Java because:
- Business requirements have changed. The pace of change has increased.
- Development authoring is limited to programming languages. Even though the Java platform supports additional programming languages such as Groovy and JRuby, the underlying platform limits innovation to the traditional services provided by Java. You can invent as many new programming languages as you want, but they must all be implementable in the underlying platform.
- Java bungled the presentation layer. Swing is a nightmare, and JavaFX is a failure. JSF was designed for pre-Ajax user interfaces even though some implementations such as ICEfaces incorporate Ajax. There is a steady stream of new UI approaches reflecting Java’s lack of leadership in the presentation layer.
- Java frameworks prove complexity. Hibernate, Spring, Struts and other frameworks reveal Javas deficiencies rather than its strengths. A future platform shouldn’t need a cacophony of frameworks just to do the basics.
- Java is based on C++. Is this really the best way to develop enterprise business applications?
- Javas new boss is the same as the old boss. Oracles reign is unlikely to transform Java. Oracles recent Java announcements were a disappointment. They are focused on more features, more performance and more partnerships with other vendors. So far, it appears that Oracle is continuing with Suns same failed Java policies.
- Java has never been the only game in town. C# is not the alternative. It is little more than Java Microsoft style. But, there are new developer tools such as Microsoft Lightswitch and WaveMaker, and traditional but updated 4GL tools such as Compuware Uniface and Progress OpenEdge. And dont forget about business rules platforms, BPM and event processing platforms that enable faster change offers by enterprise software vendors such as IBM, Progress, TIBCO and Software AG.
Yet, Gualtieri noted that, Clear standard alternatives to Java and C# for custom-developed applications do not exist. And he exhorted app dev teams to create a three-year application development strategy and road map to include architecture, process, talent, tools and technology. The road map should clearly look at language and framework options.
Later, in January 2011, Gualtieris Forrester colleague John Rymer did a post on the future of Java, where he quite correctly said:
“Fewer young developers will learn Java first. One of Java’s greatest strengths has been the number of young developers who learn it as a first language. As Java becomes less and less of a client-side language, we expect to see educational institutions switch to other languages for primary education, ones with stronger client-side representation such as JavaScript and HTML 5. Over time, developers will begin to view Java as a server-side language for enterpriseslike COBOL.“
Meanwhile, a RedMonk ranking of programming languages from last week shows Java as the top programming language according to their methods of calculating. In a Feb. 8 post, RedMonks OGrady said:
“As recently as a year ago, Java was widely regarded as a language with a limited future. Between the increased competition from dynamic languages and JVM-based Java alternatives, while the JVM had a clearly projectable future, even conservative, enterprise buyer oriented analyststhe constituency most predisposed to defend Javawere writing its obituary. As we argued at FOSDEM last February, however, these conclusions were premature according to our data. One year in, and the data continues to validate that assertion.Apart from being the second-highest growth language on GitHub next to CoffeeScript, Javaalready the language with the second-most associated tags on Stack Overflowoutpaced the median tag volume growth rate of 23 percent. This growth is supported elsewhere; on LinkedIn, the Java user group grew members faster than every other tracked programming language excepting C# and Java. This chart, for example, depicts the percentage of LinkedIn user group growth for Java- and JVM-based alternatives since November of 2011.“
Still, there are obviously times when a development team needs to introduce a new language into their environment. Jay Fields, a software developer at DRW Trading, offers advice. Fields said introducing a new language is likely a multi-year affair for any moderately sized organization. He said he had to take on several roles and to become an expert and other things to alleviate his teammates concerns.
Said Fields:
I eased my teammates adoption fears by making the following commitments.
- If you want to work on the code I’ll work with you (if you want me to work with you).
- If you don’t want to work on the code I’ll fix anything that’s broken.
- If the initial pain of working with a new language becomes unbearable to you, I’ll rewrite everything in Java on my own time.