The Oracle acquisition of Sun Microsystems closed in January of 2010, and a road map for the various acquired technologies was drawn up soon after. Even though Java-related software represented a small fraction of Sun’s revenue, acquiring Java was the key reason Oracle made its bid for Sun. It is therefore not surprising that developers were concerned and vocal about the acquisition, even though Java was simply passing from one vendor to another.
Java, in fact, passed from a hardware-focused company to a software-focused company, and many feared that Oracle would be much more effective at monetizing it, potentially upping licensing fees, withdrawing it from open source, or evolving it autocratically. Let’s take a look at how Oracle has performed with Java.
Java evolution and the JCP: When Oracle acquired Java, the technology’s anchor codebase of Java SE (Standard Edition) was in limbo, heavily weighed down by a huge set of planned improvements for Java SE 7. Meanwhile, the Java governance process (JCP) was stalled by an Apache request for a Test Compatibility Kit (TCK) to certify a parallel Java implementation known as Harmony. Key members of the JCP, such as Apache and IBM, were at loggerheads with Sun over the TCK, which Sun neither provided nor explicitly denied.
Soon after the acquisition, a more decisive Oracle moved to clarify its position on parallel implementations of Java, and so denied the TCK request. This precipitated the departure of the venerable Apache Software Foundation from the JCP, but succeeded in bringing the two largest Java players on the same page. Having resolved the governance conflicts with the JCP, Oracle then pushed through a more realistic plan to deliver the planned Java changes by splitting them into two releases.
Java SE 7 finally shipped in July 2011, almost five years after its predecessor, bringing improved support for dynamic languages and enhancements such as allowing strings in a switch statement (project Coin), among others. Java SE 8, which carries the more ambitious changes initially promised by Sun, will bring modularity (Project Jigsaw), lambda expressions, and a number of additional changes such as Java FX capabilities accessible directly from the Java language instead of a separate scripting language. Java SE 8 is scheduled for mid-2013, and its delivery will be a key test for Oracle’s execution on Java.
The future of Java open source: The Java community may be divided over Oracle’s position on whether to have parallel implementations of Java, but everyone appreciates that Java is finally evolving, still governed by a process of consensus, and remains open source. In fact, Oracle decided to use the open-source version of Java, called OpenJDK, as the reference implementation for Java.
While OpenJDK keeps all source code locked in a GPL license (preventing other vendors from monetizing it without licensing), it fulfills the need of the community to understand the implementation deeply, and allows other vendors to participate in the development of the code. In fact, Oracle was successful at bringing IBM, Apple and SAP to the OpenJDK table in the last 18 months, bringing new credibility to the project. This turnaround in Oracle’s open-source fortunes comes in contrast with Oracle’s early conflict around the OpenOffice codebase, which it later contributed to the Apache foundation to manage after the community forked it into LibreOffice.
Overall, Oracle has pragmatically pruned its open-source portfolio to what it believes it can drive forward effectively, and that is probably as good as can be expected. It is safe to say that not only did the Java community’s worst fears not materialize, but Oracle, after picking up its game in open-source and vendor diplomacy, has been instrumental at moving Java from an at-risk state to a technology on a decisive strategic rebound.
From language to ecosystem: Over the last few years, Java has grown to something much greater than a single programming language. Java was conceived as a language supported by a rich runtime to allow for transparent portability along its key premise: write once, run anywhere (WORA). The WORA requirement relied on a design based on an abstract virtual machine, known as the Java Virtual Machine (JVM), which executed translated or compiled instructions (bytecode). This capability opened the door for the support of other languages, and was in fact exploited shortly after Java was born.