The Eschatology of Java
I published an article titled “The Eschatology of Java” on the August 2013 issue of JAX Magazine
The Full-Text Version
“What is the future of Java?” is a question that comes up quite often, and every time it does, the blogosphere gets riled up with everyone putting in their two-cents worth. Amateurs and the experts alike engage in never-ending polemics that often go off on tangents and get nowhere. The answer, if there actually is one, is lost in the overload of infobesity and the haze of conflicting emotions.
I take no issue with the question being asked as it is cer- tainly a legitimate one, if not of extreme importance. In fact, it should be given serious thought, whether you are a veteran with a lot invested into Java, a noob trying to figure out what is worthwhile, or just a self-proclaimed Java hater.
Throughout the years, I resisted the urge to write about this very question realizing its non-trivial nature. Recently, after another one of my Java talks, I found myself, once more, en- gaged in a lengthy discussion about it. Only then did I realize that I have built up enough courage to write this article; not so much to partake in the argument, but to humbly share my thoughts and my personal efforts to achieve some clarity. All I promise is my biased impressions and the memory-dump of an opinionated mind that spent years brewing Java. It would be then up to you to figure out what to make of it.
The Java Late-Night Talk Show
It doesn’t take much time following “The Java late-night talk show” to realize that the pundits generally fall into two main camps in the way they address the question.
The first camp is that of “the eggheads”, who tend to enumerate the features of every programming language on 99-bottles-of-beer.net , and spend time discussing which ones Java lack and which ones it needs to have. Depending on the current fad and the individual’s beliefs, you end up hearing different opinions favorable and unfavorable. It is ei- ther that Java’s doomsday is near or that the future of Java is as bright as the sun (no pun intended). For the pessimistic “egghead”, 2012 happens every time a feature doesn’t make it into the next anticipated release, or a new vulnerability is discovered in the current version.
The second camp constitutes of “the romantics”, who go on citing the TIOBE Index  making the case that Java is still the most popular programming language after all, and that it will remain so because of the community around it.
Both sides put up much more elaborate arguments than this, some so articulate that I find myself gravitating toward one side. What I could not ignore is the fact that the way both camps deal with the question is fundamentally wrong.
The case against the “eggheads” is the argument that you can only evolve a language so much. Some features are simply impossible to implement, and some are just not consist- ent with the philosophy that drove the initial design of the language to begin with. This is assuming that the proposed change is genuinely needed and arguably in the right direc- tion. The reality is that a technology doesn’t need to be the “hottest” to stay relevant. It can withstand the winds of change. It only needs to be “hot enough”, and by that I mean it supports the set of features that fulfil the needs of the gen- eral use case at some point in time.
In contrast, being the ‘hottest’ is not always enough for a technology to reach massive adoption either. The paradigm only shifts in its favour when something is so ‘hot’ it renders the status-quo “unhot”. In layman’s terms, people will hang out as long as they are being entertained, or until the curtain goes down.
As for Java, it is certainly ‘hot enough’. I also don’t see any- thing serious enough out there nearing the tipping point of disruptive ‘hotness’. This is despite of Java’s long overdue fea- ture wish-list and the series of disappointments release after release. The fact that many new open-source projects and a long list of major software shops still adopt it as the language of choice is a strong indicator that Java hasn’t lost its mojo.
As much as I dislike indiscriminately discrediting anyone, I advise you to think twice before wasting your time when you come across one of those “tabloid blogs” featuring bold titles like “is Java Dead?” or “The Java Postmortem”. It is highly likely that some new technology has emerged, and quickly gained itself a bunch of excited fan boys.
“The romantics” don’t fare much better. The idea that a technology will sustain its success because it is well-adopted and enjoys a large following is a very superficial one. The correlation between the viability of the technology and the health of its community does not mean that one caused the other. On the other hand, a healthy community merely re- flects current success, and doesn’t say much about the future. To measure present success, one can certainly consider the current state of community as an indicator, but he or she can’t make any predictions about the future on that basis.
As far as Java is concerned, there is no doubt that the com- munity around it is as healthy as it gets. Speaking from per- sonal experience as a JUG (Java User Group) leader myself, it is truly a unique one. It is sizable, highly-diverse, and not passive by any means. The Java community members are not only enthusiastic and passionate users of the technology, but also highly involved in its development and evolution. Con- tributions to OpenJDK and the success of the Adopt-a-JSR project speak volumes for this.
The point of the lengthy “egghead” and “romantic” bash- ing is not to paint an unrealistic grim picture, or to suggest that the controversy is so polarized it leaves no room for a third more reasonable crowd. On the contrary, the silent ma- jority is from neither camp. It lands somewhere in between establishing “the grey area” argument; a stance that acknowl- edges the merits of all ideas brought forth by both sides, and reconciles both points of view one way or another.
I put this question off for a long time, and avoided giving it any serious thought. I guess, it was just easier to join the peo- ple on the fence. One day, I was working with my brother on a project, and he suggested to use Ruby instead of Java. The discussion went on for a while, and involved some serious questions being asked. What came out of it is the realization that the future of a technology is neither determined by the technology itself nor the community around it. For instance, neither Java itself nor the Java community gets to decide the future of Java. But who or what decides then?
Survival of the Fittest
After obsessing over this, somehow I ended up wonder- ing about applying the biological concepts of evolution to programming languages. The idea of “Programming Lan- guages Darwinism” was very appealing to me, and made total sense. In evolutionary biology, species evolve by the process of natural selection. Individual organisms that pos- sess certain traits are either the most fitted or the least fitted vis-a-vis their environment; hence, the most likely to thrive or the most likely to die off respectively. In other words, it is the environment that decides the fate of the species by establishing a bias toward favorable traits and against un- favorable ones.
Projecting this onto programming languages, Java includ- ed, it is the environment within which they are used that de- cides their future.
This invites another question. What the hell does “the envi- ronment” mean within the context of programming languag- es? The answer is surprisingly a simple one. It would be the hardware on top of which it runs, and the nature of problems it is used to solve. The success of Java for instance must be attributed to its fitness to solve current problems on current hardware. It is only reasonable to assume that as long as “the environment” stays unchanged, Java will continue to be the successful language it has always been.
The Paradigm Shift
A decade ago, the target hardware to execute the binary was the least of the concerns of software practitioners, unless of course they happened to be in the embedded space. Java folks couldn’t have cared less either. They didn’t even have to know the target architecture to compile for; thanks to the JVM that truly delivered on the promise of write-once run-anywhere. On another front, Moore’s Law proved to be remarkably accurate. As machines got exponentially faster, the perfor- mance gain was automatically realized by the software. In other words, code simply ran faster on faster hardware. Life was good, but nothing is forever.
As predicted by physicists, Moore’s Law could not be sus- tained. Heat and leakage constraints imposed by the laws of thermodynamics and quantum mechanics simply limit how much computing power we can fit on the one silicon chip. This marked the end of an era, as we started building comput- ers with multiple cores.
The hardware change was pretty significant if not radical. To understand what this means for the world of software, we must first spend some time ruminating over the imperative programming paradigm. This model is the most familiar to developers being adopted by the most popular programming languages including Java.
Within the imperative paradigm, computational instruc- tions are expressed as sequences of statements with the side- effects of mutating state. Despite being the most intuitive, it can pose a significant challenge to developers as it burdens them with managing state. A problem that only gets hard- er when parallelism is at play; requiring state mutation and access to be synchronized across concurrently executing threads. As developers, we have been dealing with this head- ache by relying on abstractions (libraries and frameworks), or by incorporating immutability in our design. On new multi- core hardware, state will need to be managed not only across threads but also across cores. This is a nightmare to deal with at best if not humanly impossible. So, we end up writing code that is incapable of taking advantage of the full computing power of the hardware, and is limited by the maximum clock rate the silicon chip can support. This can only mean one thing; the paradigm is shifting, and the rug is being pulled from under imperative programming languages. Java is no exception!
The Return of Functional
In the quest for the alternative, we find ourselves escaping the abyss of imperative state management into the chasm of the functional paradigm, where there is no state to be man- aged. A plethora of new languages were introduced into the mainstream, some of which we resurrected from the hades of academia after decades of collecting dust. We have officially gone retro.
So, what is going to happen to Java? Before we go any fur- ther, allow me to make the important distinction between Java “the language” and Java “the platform” as both have been evolving independently toward separate fates over the past few years.
It is my belief that it is only a matter of time until Java “the language” becomes another COBOL  along with every other imperative language. They will all undoubtedly phase out in the ways of those before them to become fossils for the language archeologists to examine . This will take a long time, and will be a gradual process considering how much we have invested.
The feverous race to add functional features to these lan- guages is desperate. It is like putting lipstick on a pig. As I mentioned at the beginning of the article, we can only evolve a language so much. The paradigm shift is so radical that a language like Java simply cannot manage to reinvent itself in that direction, and still be called Java. It will become a dif- ferent language all together. Besides, I can’t possibly think of anything more painful than pretending to be all functional in Java with its imperative memory model working against you. If you enjoy banging your head against the wall and going through hoops to do the most trivial of tasks, be my guest.
I am not suggesting here that adding lambdas to Java (JSR 335) for example is a mistake. In contrary, I think it is the best thing that has happened to Java in a long time. I am just making the point that we should be careful not to get carried away, and turn it into a bloated franken-language in the liking of C++. After all, we would only be prolonging the lives of comatose languages by putting them on life support. Sometimes it is best to make peace with things the way they are, and let go.
On the bright side, Java “the platform” is a completely dif- ferent story. The once-ambitious goal of providing first-class support for other programming languages on the JVM has become a reality; thanks to the effort that was put into The Da Vinci project (JSR 292). This did not only make new lan- guages easy and possible to implement, but also addressed some of their native performance issues, leveraging the expe- rience accumulated from improving the Java runtime over the years. Today an increasing number of languages run on the JVM, many of which are functional with all the promises the future holds for them .
There is no doubt in my mind that Java “the platform” is going to outlive Java “the language”. One day, we will find ourselves with the JVM without Java. In the words of Martin Fowler “The legacy of Java will be the platform, not the lan- guage”. For a good read along these lines, I recommend Neal Ford’s new series java.next on developerWorks .
The nature of problems Java is used to solve has as much of an impact on its future as the hardware it runs on. As a ge- neric programming language, Java proved itself fit for almost every use case. Its historical success on the desktop paved the way for an even bigger success in the enterprise. Server-side Java matured an impressive technology stack of standardized APIs to attend the needs of the most complex requirements. The rise of social blurred the line between enterprise and con- sumer applications, making the latter as complex if not more demanding. As other platforms struggled, JEE (Java Enter- prise Edition) was becoming even more appealing with the release of JEE 5 that shifted the focus to developer productiv- ity and lightweight-ness. The cloud computing revolution and the emergence of PAAS was the cherry on top. The deploy- ment barrier was rendered irrelevant making server-side Java even more accessible.
For a long time, the mobile space was plagued with fragmen- tation, constrained hardware, and scarce data connectivity. Only Java in its ME (Micro Edition) version could success- fully provide a programming model that unites all. Mobile Java enjoyed years of success until the introduction of smarter devices sealed its fate. Java ME, which was spread so thin, was struggling to keep up with the fast-changing landscape, and found itself incapable of delivering its promise.
The irony is that what once worked to its advantage is now contributing to its demise. In the midst of the confusion, Sun introduced JavaFX, a new technology that was meant to solve the wrong problem. In the absence of a Java phone, it focused on providing a richer platform on every device, and failed just as much. Today JavaFX is significantly different.
At a critical time, Google put a ton of resources behind Android, and managed to successfully fill a void left by a de- ficient Java ME and the teetering JavaFX at the time. No one can deny that it gave “Java” a much-needed rejuvenating jolt and introduced it to a wider audience.
One might argue that Android is Java’s strong foothold in the mobile space. That is only true if you happen to believe that Android is Java. I beg to differ. On the Android platform, Java classes are compiled into a binary that is nothing like the Java byte code, and executed on Dalvik, a virtual machine that is not only different than the standard JVM, but architec- turally incompatible. Besides, the Java standard class library, including some classes in java.lang, is not fully supported, and sometimes even implemented in a way that is counter- intuitive to the Java SE developer. Android in this regard has gutted the soul of Java by opting for Dalvik.
In my opinion, Android was not good for Java; Android was good for Android. It dangerously compromised the fu- ture of mobile Java in the sense that it diminished the role Java has always assumed as the platform, and stripped it down to the syntax of the language. One can realize the extent of the damage if he or she considers the context of the paradigm shift in favor of functional languages as discussed earlier. It is naive not to question Google’s intentions regarding Android. The “business” decision of going with Java without going with Java invites a lot of doubt. The genius of it is that it al- lowed them to reap, with minimal risk, all the goodwill of the most popular programming language. It is also important to highlight that they didn’t have much of a choice at the time.
How about Java on iPhone? Apple has long cherished Objective-C, a mutt programming language it inherited from the days of NeXT. Nobody loves Objective-C, but Apple can do no wrong. The success and beauty of the iOS platform bewitched us into overlooking the language’s ugliness and verbosity.
Being able to write Java apps on the iOS platform happened to be too much to ask from Apple, which neither provides a native JVM on iOS devices, nor allows 3rd parties to port it themselves. This is very understandable in light of the recent patent wars between Google and Oracle over the Java API , and the company’s apparent desire to self-sufficiently rely on technologies it has control over.
In an article published on infoworld.com , James Gos- ling, the creator of Java, suggested that the new JEP (JDK Enhancement Proposal) 178 could be Java’s Trojan horse to conquer the well-guarded castle of iOS. The enhancement aims to “modify the Java SE specification and the JDK (Java Development Kit) to enable developers to package a Java runtime, native application code, and Java application code together into a single binary that does not require the use of shared libraries”.
This sounds like a great workaround, but it is not chal- lenge free. I see several serious problems. The most obvious of all is that the JVM binary will significantly increase the size of the final shippable apps. Project Jigsaw (JSR 337), which has been dragging since its inception in 2008, might actually make this less of a concern by allowing developers to weed out the JVM modules their apps don’t need. Another concern is Apple’s notorious App Store approval process, whose terms are subject to change anytime. It wouldn’t be surprising if the company decides to boot out all Java apps from the store one day, if they allowed them in to begin with. If we were to assume that the size of apps is a nonissue and that Apple is Java friendly for some reason, we would still have to face the challenge of writing Java apps of comparable quality to na- tive iOS ones. The flagship technology to develop desktop and embedded applications on Java is JavaFX. If it is to be used to write iOS apps, we will need support for iOS controls and a native look-and-feel consistent with Apple’s design guide- lines, a full-featured API to take advantage of Apple’s hard- ware, and many more missing features. The most important asset JavaFX brings is outstanding performance in handling audio, video, graphics, and animations; arguably, one that is superior to what the iOS platform has to offer. Unfortunately, this will be untapped; according to Gosling “the JIT code gen- erator has to be turned off” . This positions Java on iOS at a huge disadvantage to the point that one is better off using PhoneGap-like HTML5 technologies instead.
In my opinion, the state of mobile Java is concerning to say the least. The biggest fear is that if things remain the way they are, we will go from Java runs everywhere to Java runs nowhere!
The Elephants in the Room
I couldn’t end this article as if the recent security exploits are not comment-worthy, or that Oracle didn’t sue Google over Java. Allow me to lay this to rest. With the publishing of early reports, the fear mongers cried: “disable insecure Java!” like no other technology is prone to security threats.
Sarcasm aside, most of the recent vulnerabilities only af- fect the Java browser plug-in, where untrusted malicious code can be downloaded by clients and executed within their local JVM. In one instance, the security manager can be reflectively disabled leaving the door wide-open for all kinds of prob- lems. As harsh as it sounds, if you are still writing Java Ap- plets in 2013, blame no one but yourself; the chickens have come home to roast. Maybe it is time for you to consider delivering your software as a web application instead.
I am not saying this to engage in victim blaming or justify Oracle’s screw up. I am being deliberately offensive to draw attention to the fact that an architecture that relies on a cli- ent runtime comes with such risk. Oracle has been generally on top of this, and usually released patches within days of incidents. The problem is that only 5.5 % of browsers were running the most current version of the Java plug-in as of March 25th, 2013 . One cannot deny the developer’s re- sponsibility to ensure that his or her application is using the appropriate version of the runtime. The failure to build-in a mechanism to require a specific version of the JVM or force the client to update makes it hard to simply drop it all on Oracle’s lap. If you are interested in updates and more infor- mation, check out the latest from Oracle’s Software Security Assurance Blog .
Oracle’s acquisition of Sun Microsystems gave the Java community all the reasons to be concerned. Besides the fact that the two companies had very different attitudes toward open-source software, it was no secret that Oracle was more interested in Sun’s hardware and didn’t care much for Java.
Back in 2009, I wrote a blog post titled “Oracle/Sun Merg- er a Community Perspective”  to record my impressions at the first OOW (Oracle Open World) conference after the announcement was made. Anyways, my overall attitude was reserved and somewhat unsure. I was reassured by that fact that Java is open-source.
In retrospect, despite of all criticism and speculations, the acquisition turned out to be positive for Java after all. Yet some of Oracle’s actions send mixed signals. Oracle is doing a fairly great job in its efforts to develop the technology and engage the community through continuously supporting the JUGs, improving the communication, and reforming and simplifying the JSR process. However, its lawsuit against Google in an attempt to copyright the Java APIs is noth- ing but a confirmation of everyone’s first fears. The court, fortunately, ruled in Google’s favor deeming the Java APIs non-copyrightable because they are functional in nature and are required by others to use the Java language . I have not met a lot of people that did not feel relieved about the court’s decision. There is no doubt in my mind that had it been up to Oracle, Java wouldn’t have been open-sourced. The decision to free Java remains Sun Microsystems’s great- est legacy. RIP Sun!
The Java Tasseography
If reading through this article gave you the impression that I have the definitive answer of what the future of Java looks like, I apologize for having misled you. The truth is that I don’t really know, and would argue that everybody is just speculating as much. This is one of those questions better asked to a palm reader in the old souks of Marrakech, or a fortune-teller in the streets of Stolipinovo.
Now, you can spend your time reading into the visible ex- halation of vapor rising from that steamy cup of Java, asking yourself “Is it really as hot as it seems to be? Or is the temper- ature of the room just too low?” I say take a sip before it gets too cold to drink when all the vapor there is to be is diffused through the air. We all know it’s been there long enough not to burn your tongue.
Que sera sera…