The Eggheads vs The Romantics

Java hasn’t lost its mojo

AbdelmonaimRemani
java-baby2

“What is the future of Java?” is a question that frequently riles up the blogosphere. Abdelmoniam Remani gives us his two cents.

“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
certainly 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, engaged 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 [1], 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 either 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 [2] 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 consistent 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 direction. 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 general 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 anything serious enough out there nearing the tipping
point of disruptive ‘hotness’. This is despite of Java’s long
overdue feature 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 reflects 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 community around it is as healthy as it gets. Speaking from
personal 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. Contributions to OpenJDK and the
success of the Adopt-a-JSR project speak volumes for
this. 

The point of the lengthy “egghead” and “romantic”
bashing 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 majority is from
neither camp. It lands somewhere in between establishing “the grey
area” argument; a stance that acknowledges 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 people 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 wondering about applying the biological
concepts of evolution to programming languages. The idea of
“Programming Languages Darwinism” was very appealing to me, and
made total sense. In evolutionary biology, species evolve by the
process of natural selection. Individual organisms that possess
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 unfavorable
ones.

Projecting this onto programming languages, Java
included, it is the environment within which they are used that
decides their future.

This invites another question. What the hell does “the
environment” mean within the context of programming languages? 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 performance 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
sustained. 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 computers 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
instructions 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 harder 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 headache 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 managed. 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
further, 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 [3] 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 [4]. 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
languages 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 different
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 different 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 languages easy
and possible to implement, but also addressed some of their native
performance issues, leveraging the experience 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 [5]. 

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 language”. For a
good read along these lines, I recommend Neal Ford’s new series
java.next on developerWorks [6].

Nephologia

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 generic 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 consumer applications, making the latter as complex
if not more demanding. As other platforms struggled, JEE (Java
Enterprise Edition) was becoming even more appealing with the
release of JEE 5 that shifted the focus to developer productivity
and lightweight-ness. The cloud computing revolution and the
emergence of PAAS was the cherry on top. The deployment barrier was
rendered irrelevant making server-side Java even more
accessible.

Mobile

For a long time, the mobile space was plagued with
fragmentation, constrained hardware, and scarce data connectivity.
Only Java in its ME (Micro Edition) version could successfully
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
deficient 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 architecturally
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 future 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 allowed 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 [7], and
the company’s apparent desire to self-sufficiently rely on
technologies it has control over.

In an article published on infoworld.com [8], James
Gosling, 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
challenge 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
native 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 guidelines, a
full-featured API to take advantage of Apple’s hardware, 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 generator has to be turned off” [8]. 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
affect 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 problems. As harsh as
it sounds, if you are still writing Java Applets 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
client 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 [9]. One
cannot deny the developer’s responsibility 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 information, check out the latest from Oracle’s Software
Security Assurance Blog [10]. 

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
Merger a Community Perspective” [11] 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 nothing 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 [12]. 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
greatest 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
exhalation of vapor rising from that steamy cup of Java, asking
yourself “Is it really as hot as it seems to be? Or is the
temperature 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…

This article was originally featured in the June
edition of JAX Magazine.

Image by waferboard

Abdelmoniam is a software developer and technology
enthusiast at heart and by profession, particularly interested in
technology evangelism and enterprise software development and
architecture. Abdel is experienced in Java Enterprise Applications
and a wide range of related technologies. He is President and
Founder of a number of organizations namely The NorCal Java User
Group, The Silicon Valley Dart Meetup, and The Silicon Valley
Spring User Group. Abdel is a frequent speaker at a number of
developer conferences including JavaOne (was named a JavaOne
Rockstar), JAXConf, OSCon, OREDEV, and many user groups and
community events.

References 

[1] http://99-bottles-of-beer.net/

[2]

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[3]

http://www-03.ibm.com/press/us/en/pressrelease/41095.wss

[4] [3]

http://oreilly.com/news/graphics/prog_lang_poster.pdf

[5]

http://en.wikipedia.org/wiki/List_of_JVM_languages

[6]

http://www.ibm.com/developerworks/library/j-jn1/

[7]http://www.computerworld.com/s/article/9239658/Computer_scientists_oppose_Orac
le_39_s_bid_to_copyright_Java_APIs

[8]

http://www.infoworld.com/t/java-programming/gosling-new-java-proposal-could-

ease-ports-ios-213843

[9]

http://community.websense.com/blogs/securitylabs/archive/2013/03/25/how-are-

java-attacks-getting-through.aspx?cmpid=slbl

[10]

https://blogs.oracle.com/security/entry/june_2013_critical_patch_update

[11]

http://blog.polymathiccoder.com/post/53583500559/oracle-sun-merger-a-

community-prospective [12]

https://www.docketalarm.com/cases/California_Northern_District_Court/3–10-

cv-03561/Oracle_America_Inc_v_Google_Inc/1190/

Author

AbdelmonaimRemani

All Posts by AbdelmonaimRemani

Abdelmonaim is a software developer and technology enthusiast at heart and by profession, particularly interested in technology evangelism and enterprise software development and architecture. Abdel is experienced in Java Enterprise Applications and a wide range of related technologies. He is President and Founder of a number of organizations namely The NorCal Java User Group, The Silicon Valley Dart Meetup, and The Silicon Valley Spring User Group. Abdel is a frequent speaker at a number of developer conferences including JavaOne (was named a JavaOne Rockstar), JAXConf, OSCon, OREDEV, and many user groups and community events.
Comments
comments powered by Disqus