Google’s Android N Will Move to the OpenJDK – InApps 2022

The next version of Google’s mobile operating system, Android N, will soon be upon us and when it arrives, regardless of what tasty treat it will be named after, it will not use Google’s implementation of Oracle’s proprietary Java APIs.

After much speculation when users of the Ycombinator Hacker News forum discovered “mysterious” git commits on the Android codebase, Google has confirmed the next version of Android won’t implement Oracle’s proprietary APIs to VentureBeat. The next version of Android will instead use an open source implementation of the Java Standard Edition; OpenJDK.

OpenJDK is a free and open source implementation of the Java Platform Standard Edition sanctioned by Oracle. Unlike the now retired Apache Harmony implementation — which most of Android’s Java APIs are currently derived from — OpenJDK is licensed under the more restrictive GNU General Public License, meaning any code changes or fixes must be contributed back to the community at large. Since the demise of Apache Harmony after failing to obtain a Technology Compatibility Kit license from Sun Microsystems, OpenJDK has become the defacto Java SE implementation in many software development circles.

There are a number of reasons why Google would want to make such a change. A Google spokesperson told VentureBeat they plan on creating a common code base for developers to build apps and services. Google has worked with and contributed to the OpenJDK community; with the spokesperson saying “As an open source platform, Android is built upon the collaboration of the open source community.”

With Java 8’s release last year came a number of features for developers, such as Lambda Expressions. Android developers will also appreciate the better compatibility with Java libraries as many libraries are starting to require Java 8. OpenJDK has been the official reference implementation of Java since 2011, this will make it much easier for developers to port code originally written for non-mobile platforms. As VentureBeat speculates, there is another reason Google would want to make the change from Oracle’s proprietary Java SE implementation, namely its legal battle with Oracle.

Google v Oracle

Although Android is currently dominating the mobile device market share with over 82 percent of smartphones running on the operating system, it has its fair share of important and costly battles.

One important legal battle facing Google is its implementation of Oracle’s Java APIs. In the release of the Android SDK in 2007, Android included the Apache Harmony implementation of a subset of the Java SE. Apache Harmony has since been retired and Google has been replacing its implementation for a while now.

After Oracle bought Sun Microsystems in 2010, the original developers of the Java language and its standard libraries, it sued Google for copyright and patent infringement the same year. The legal battle is still going on; with its final decision expected to have huge consequences not only for Oracle and Google, but also the amount of power big tech companies have in determining how new software is developed, and how much fair use laws and open source licenses protect the use and implementation of APIs.

In the meantime, with the court ruling by Federal Circuit Court of Appeals, reversing an earlier district court decision and affirming that the “structure, sequence and organization” of an API was copyrightable in Oracle’s favor, it may make a lot of sense for Google to do away with their Java APIs implementation and use the Oracle-sanctioned OpenJDK.

Regardless of Google’s reasons for using the OpenJDK Java APIs implementation, the use of a unified open source Java SE should be good for developers. End users of the Android Operating System will almost certainly not notice the change and it will be a long time before Android N and its successors come to dominate the Android version market share, but the future of Android with OpenJDK is one worth looking forward to.

Feature image: “Coffee Beans” by Unsplash is licensed under CC0 1.0.