Java? Nah, I do JavaScript, man. Wise up, hipster, to the money

If you ‘ain’t coding Java EE, it’s telling you what to deliver

A while back I answered my door bell - it was the pizza. After transacting for the hot pie, the older delivery man with a Just Like Dear Old Dad mustache asked: "Are you a programmer?" pointing to the OpenStack logo on my hoodie sleeve. "Yes," I said, "well, I used to be." He asked me what programming language he should learn and quickly added "JavaScript?"

Taking the pizza, I said: "Java. There's lots of jobs in Java."

"You mean JavaScript?"

"Well, I mean, everyone knows JavaScript. But there's always work in Java."

Java is the great shoggoth of the programming world. Seemingly eternal, ever shifting and growing, but above all massive enough to mindlessly roll over any competitors, even the withering of time. Over the years, Java has been declared dead many times, but despite numerous visits to the grave it has constantly remained one of the top three languages in use.

The nature of Java changes constantly, and despite an ever-fragmented and quarrelling community and coming and going vendors, what seems like disorder is a wonderful advantage of constant adaptability and, thus, stability over time. The most recent fear and uncertainty comes from a shift in the nature and usage of Java’s enterprise-y face.

The money in Java

The business – nay, “enterprise” – version of Java has always provoked the most vitriolic responses from the overall development community. “Why do we need all this bulk?” the Ruby and Python kids have always harrumphed in their tight pants. “Why don’t we just code this mortgage application approval workflow in Go?” the shiny object squirrels on Hacker News comment.

But like a baffled, aloof grey-hair in dad jeans, squinting over his glasses at that hand-sized Android phablet, Java Enterprise Edition (Java EE) chugs along. This variant of Java aims to add in the common frameworks used by organizations to go all “enterprise grade” in their applications: transactions, RBAC, database integration, standard methods for web development, and numerous other components all corralled together into a standard stack.

Most of the these components can be used on their own - most famously the servlet spec which defines a widely used method for writing web applications - but having the all-in-one kit is supposed to afford you the usual 1 + 1 = 3 benefits. The additional angle vendors of Java EE stacks trade on is actual production performance and manageability: that silo’ed bundle of uptime needs for the pre-DevOps set.

As you’d expect from anything going by the nom de guerre “enterprise,” Java EE products and services have driven a huge amount of revenue for decades in the Java world. In 2015, Gartner estimated that the application platform market was $7.8bn. But share of Java EE revenue in that mix has been shrinking in favour of non-Java EE options. The lions of the Java EE market, IBM and Oracle, have been dropping in revenue share while non-traditional Java EE vendors have been rising quickly, with growth in the double digits in 2015.

Looking back, Java EE has been an incredibly reliable bucket of technologies, running numerous, mission critical applications across companies of all sizes. Plenty of colorful personalities have come and gone and repeatedly kicked over rose-scented piles of Java muck to the delight of train-wreck coroners like myself. For example, the ever bombastic and florid JBoss crew and their head iconoclast, Marc Fluery, never failed to delight in calling out the slow Java standard process and mercantile interests of Java vendors.

In exactly the opposite direction of sharp-elbow pizzaz, the calm and plodding Spring community led by Rod Johnson slowly changed the usability and nature of Java development as a sort of friendly rebel next door.

Both of these communities sought to strip down the “bloat” of Java, making it smaller, and easier to use. Like so many Java startups, each of these firms was gobbled up by the mainstream: JBoss was acquired by Red Hat in 2006, while Spring found its way first into VMware in 2009 and then into Pivotal (my employer).

Dead again

Last year, a report from Gartner declaring the end of Java EE’s dominance invigorated all the latent tension in the community. As one of the report’s authors put it: "People don't need 90 per cent of the stuff sitting in Java EE to build modern enterprise applications.”

Predictably, such statements drove counter-arguments of analyst payola and ignorance in the ever-delightful ad hominem style (I'm looking forward to finding out how much of a moron I am this time in the comments section - KISSES!). Vendors who benefited from a decline in Java EE only offered wry smiles and download figures, while the original analysts gave the equivalent of a tired shruggie as they stuck by their guns and pdf-splained their original analysis.

What gets lost in this near annual Java flagellation is that Java's ever-green viability and usefulness is driven by its ever evolving nature. What worked in one decade isn’t the best approach in the next. Early on, Java and Java EE were the equivalent of a fully operational battle battle-platform, loaded with features that could dominate any transactional workload to space-dust.

It also provided a widely understood standard for enterprises development: you could easily find programmers who knew the stuff and didn't need training. That aircraft carrier is overkill for today's buzzword-blizzard of architectures (micro services! Cloud Native!), and now, a stripped down Java that centers around agility, speed, and (still!) reliability is the endless hunger Java is feeding.

You see this in usage of Java EE as reported in the long-running Zeroturnaround Java surveys: in 2014, usage of Java EE was at 68 per cent and this year has declined to 58 per cent.

Meanwhile, interest in Java remains strong: IDC estimated that there were five to seven million Java developers in 2016. While Java EE as a lifestyle may be on the wane, Java as a whole is holding strong. There’s been some recent threats from Go and Swift, but reports from firms like RedMonk show Java’s amazing ability to go along with changes in the industry and stay on top.

Oracle’s occasional, goofy product management decisions since acquiring Sun Microsystems (the original steward of Java) has made the community nervous over the years. There have been delays (I mean, it’s software after all - delays are a feature, not a bug) that have slowed down the evolution of the official Java standard, but open source members of the community have stepped in over the years to keep the train moving.

Oracle’s continued pursuit of lawsuits and occasional licence true-ups have a tendency to freak the community out as well, but more provide blog-screed fodder for the loyal opposition. And, you know, maybe it’s sometimes worth paying for something that your entire business relies on - just sayin’.

However it gets packaged up and sold, Java consistently ends-ups satisfying the application development and runtime needs of most organizations, from desktop, to cloud, to pocket-computer. “We just like roaches, never die, always live."

Despite all the inside-bickering, lawsuits, a shotgun wedding to Oracle, drawn-out releases, and rivals from PHP, to Rails, to Swift, Java is still in wide use and shows no signs of finally dying. Jobs-wise, you’d be hard-pressed to find a better language than Java as your primary programming language if you wanted to switch from dropping off hot-pies to writing code.

As they say in this “gig economy” world: you’re either delivering pizzas according the code-dictates of a programmer, or writing the code to tell pizza delivery drivers which door to knock on. ®