James Governor's Monkchips

Java’s late flowering

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

At the risk of starting from the beginning, which is somewhat unfashionable these days in these days of Netflix box sets with complex chronologies, I am going to start at the beginning.

Java, the language, was introduced on May 23, 1995, just as the Internet took off. Netscape’s initial public offering was just a couple of months later, on August 9th. The fates of Java and the Net have been entwined ever since. Originally intended for embedded applications, Java swiftly became the server side language of choice for enterprises and first wave Internet companies like eBay, eTrade and a cheeky little retail outfit called Amazon. Over time 3 different configurations were established for different use cases – Java 2 Mobile Edition (J2ME) for mobile devices, Java 2 Standard Edition (J2SE) for desktop apps and lightweight server side apps and Java 2 Enterprise Edition (J2EE) for transactional applications.

Between 1995 and 2000 Sun Microsystems, the creator of Java, had a license to print money – not by selling Java but workstations and servers running its Unix variant, called Solaris. As the dotcom boom boomed, so did Sun. For nearly 5 years the company could barely keep up with demand. It’s success in hardware though meant that Sun never nailed down key business model and governance issues around Java (or its server business for that matter). IBM and BEA made billions of dollars selling their WebSphere and WebLogic J2EE servers. Sun not so much.

But when the wheels fell off the economy in 2001, Sun was in deep trouble. Everyone cut back on their spending, and Sun basically never recovered. By the time the economy recovered, Linux on commodity server hardware was ready for primetime, removing the need for expensive proprietary Unix servers. The cloud was going to run on Linux, not Sun Solaris, and the rest, as they say, is history. Oracle acquired Sun outright for $7.4bn in January 2010, following its purchase of BEA in 2008. Sun’s stewardship of Java had definitely been imperfect, but everyone knew where they stood.

And so began the next chapters for Java and Solaris.

Oracle has not historically been open source friendly. It grew up in the era of proprietary software, and is frankly most comfortable there. It is however very good at commoditising key assets of competitors, and open source can help there. For Oracle everything is historically about license fees, deals and zero sum games.

In terms of delivering on Java design goals, Sun had slipped well behind on its goals by the time of the acquisition. Oracle, unlike with other assets such as Solaris and Jenkins, didn’t make any substantive license or governance changes to Java. It essentially maintained the status quo, content to carve up the enterprise market with IBM. IBM too was pretty happy with the arrangement – designed to allow both vendors, along with Red Hat’s JBoss, to continue soaking up JEE application server maintenance fees.

Until the last few weeks, that is, when news started to trickle out that we are going to see a very very different Java going forward.

For one thing, the long running question of Java Enterprise Edition stewardship is likely to be solved by the simple expedient of handing it over to an independent standards body – likely to be the Eclipse Foundation or the Apache Software Foundation. Because who else could deal it, am I right?

David Delabassee wrote this up recently in a post Opening up Java EE.

“Java EE is enormously successful, with a competitive market of compatible implementations, broad adoption of individual technologies, a huge ecosystem of frameworks and tools, and countless applications delivering value to enterprises and end users. But although Java EE is developed in open source with the participation of the Java EE community, often the process is not seen as being agile, flexible or open enough, particularly when compared to other open source communities. We’d like to do better.

We are discussing how we can improve the Java EE development process following the delivery of Java EE 8. We believe that moving Java EE technologies including reference implementations and test compatibility kit to an open source foundation may be the right next step, in order to adopt more agile processes, implement more flexible licensing, and change the governance process. We plan on exploring this possibility with the community, our licensees and several candidate foundations to see if we can move Java EE forward in this direction.”

File this under legitimately big deal. Whatever you think of Java EE and its utility, moving it to a foundation and refactoring the JCP is a solid move, which should have been done years ago, and will help customers and the ecosystem at large. Years ago on the main stage at Java One I bastardised Churchill and said that the Java Community Process (JCP) was the worst form of governance except all the other ones we had tried. But in the intervening time the industry has got a lot better at managing open source. There is no longer a need for the kind of unwieldy approach that defined Java back in the days of proprietary Technology Compatibility Kits (TCKs) for Java Specification Requests (JSRs). That said – an open TCK model could yet show benefits for other tech communities.

Which brings us neatly to some interesting thoughts on Java Standard Edition (Java SE) – Moving Java Forward Faster – by Mark Reinhold. The evolution of Java has been extremely lumpy – but Java SE is where most of the interesting stuff has been happening. Reinhold argues the lumpiness and slowness was OK when Java had fewer competitors. Actually it was never OK, but Java could get away with it. Oracle had considered a new schedule delivering a major release every 2 years, but that was never going to be good enough – so Oracle is going to deliver a feature release every six months, and updates every quarter.

“In this model the overall rate of change should be about the same as it is today; what’s different is that there will be many more opportunities to deliver innovation. The six-month feature releases will be smaller than the multi-year feature releases of the past, and therefore easier to adopt. Six-month feature releases will also reduce the pressure to backport new features to older releases, since the next feature release will never be more than six months away.”

Oracle is trying to balance the needs of developer and enterprises, shiny vs stable. According to On the Open-JDK list Reinhold said we’d see a dual Oracle JDK or Open JDK approach for customers that want Oracle maintained or pure open source bits. The OpenJDK folks are fired up about the changes, as they should be.

Obviously anyone that has made it this far into this piece agrees with RedMonk that Java still has legs. Our programming language rankings show Java’s consistent, and somewhat surprising strength over time. Meanwhile When Web companies grow up they turn into Java shops. JVM first, then they decide Java has legs too. Much of the core innovation in Big Data platforms has been Java-based (Hadoop in Java, Spark in Scala on the JVM). Interest and attention in Spring and Spring Boot is exploding (and that’s not just at enterprises but firms like New Relic and Tesla).

Mike Milinkovich, executive director of the Eclipse Foundation, today wrote up the news – Java: free at last.

“Making Java binaries available directly from OpenJDK is going to free the Java platform for developers. Getting these directly from the platform owner, and (more importantly) having them be identical to the commercial binaries is a radical step forward. OpenJDK-based binaries will be exactly on par with, and equivalent to, the commercial ones. Although almost all of the Java source code has been open source at OpenJDK for many years, the subtle differences in content, performance, and reliability have prevented mainstream adoption of OpenJDK binaries by enterprises and industrials.

A little over a decade ago, Sun Microsystems started the process of open sourcing Java. It seems that Oracle is finally finishing the job. Good for them.”

Agreed. The contrast with Solaris this week couldn’t be more stark. Oracle just quietly laid off 90% of the engineering staff. It may be Oracle shortly make an announcement about open sourcing the Solaris code, but for now the takeaway is that Java and Solaris are very different situations. Oracle has given Java an opportunity to flourish. Better late than never to make these governance changes. It is chopping wood and carrying water.

Do I think Java EE is now going to come roaring back to relevance. No – architecturally it doesn’t make sense for the cloud native era. But the Java SE moves and governance changes are genuinely interesting, and the shift in focus is a shot in the arm for the ecosystem at large. It’s good for Amazon Web Services, Google, IBM, Microsoft, Oracle, Pivotal and Red Hat, customers, prospects and any web companies using or considering using Java.

The community benefits are the really big deal here, and could benefit Oracle more broadly in terms of a change in posture, and a willingness to be less hands off with open source communities, not just in Java but across the board. Java and the cloud will remain entwined for a while yet. It’s going to be the most interesting Java One in a decade. I am looking forward to being there.

 

 

disclosure: all the companies named above are clients. opinions expressed are purely the work of the author.

photo credit:  “echinacea purpurea” by Manuel is licensed under CC BY 2.0

4 comments

  1. Nice piece. we just have to wait and see how better it becomes

  2. […] As I said about governance, Java has changed more in the last 3 weeks than the last 13 years. […]

  3. […] has been doing some sensible house cleaning of late, for example open sourcing Java, and it was not a great surprise when Thomas Kurian, President of product development at Oracle, […]

Leave a Reply

Your email address will not be published. Required fields are marked *