Skip to main content [aditude-amp id="stickyleaderboard" targeting='{"env":"staging","page_type":"article","post_id":1857259,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"bots,business,dev,mobile,","session":"A"}']

Google confirms next Android version will use Oracle’s open-source OpenJDK for Java APIs

Google is replacing its implementation of the Java application programming interfaces (APIs) in Android with OpenJDK, the open source version of Oracle’s Java Development Kit (JDK). The news first came by a “mysterious Android codebase commit” from last month submitted to Hacker News. Google confirmed to VentureBeat that Android N will rely on an OpenJDK implementation, rather Android’s own implementation of the Java APIs.

“As an open-source platform, Android is built upon the collaboration of the open-source community,” a Google spokesperson told VentureBeat. “In our upcoming release of Android, we plan to move Android’s Java language libraries to an OpenJDK-based approach, creating a common code base for developers to build apps and services. Google has long worked with and contributed to the OpenJDK community, and we look forward to making even more contributions to the OpenJDK project in the future.”

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":1857259,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"bots,business,dev,mobile,","session":"A"}']

Android provides certain Java API libraries to support the development of apps in the Java programming language, broken into two parts: the APIs to the libraries, and the implementing code developed by Google that make said libraries work. Oracle, which develops Java, has two implementations of these libraries: the proprietary JDK version and the open source OpenJDK version. Google’s decision to “consolidate” its efforts with OpenJDK means it is moving away from its own implementing code to Oracle’s open-source code.

The code commit in question, which shows 8902 files were changed, clearly notes OpenJDK code was added to Android:

Initial import of OpenJdk files.
Create new libcore/ojluni directory with src/main/java and src/main/native subdirectiories.
Build ojluni into core-oj jar.
Use openjdk classes from java.awt.font package.
Copy all files from jdk/src/share/classes and jdk/src/solaris/classes directories in openjdk into libcore/ojluni/src/main/java.
Copy following native files from openjdk to libcore/ojluni/src/main/native: [long list of files]

This is only one commit. Google has committed several hundreds of changes to the open-source repository in relation to adopting OpenJDK.

Google is hoping that Android developers will appreciate the change because it simplifies the code on which they build apps — a common codebase for these Java API libraries, as opposed to multiple codebases. That may be true, but if that was the only reason Google made the complete switch to OpenJDK, the company would have done so years ago.

When we asked Google why now, the company pointed to to the release of Java 8 last year and the introduction of new language features such as lambdas. As such, Google wants to put more resources into OpenJDK where the team can have a bigger impact on new features and improvements. That’s the developer story Google is pitching in any case, but there’s a massive legal narrative here that can’t be forgotten.

Oracle

Hacker News users are rightly wondering whether the code commit means the legal dispute between Oracle and Google has been settled out of court, or whether Google has decided to protect itself with regards to future Android versions in the event it loses. It’s a good question, but because the Oracle lawsuit is ongoing, Google declined to comment whether this code commit is related.

After acquiring Sun in January 2010, Oracle sued Google for copyright and patent infringement in August 2010, arguing that Android cannot use Java’s APIs without permission. Google countered by declaring that APIs can’t be copyrighted as they are essential to software development, collaboration, and innovation.

In May 2012, a jury found that Google did not infringe on Oracle’s patents, adding that Java’s APIs can’t be copyrighted. In May 2014, the Federal Circuit partially reversed the district court decision, ruling in Oracle’s favor: Java’s APIs can be copyrighted. In June 2015, the U.S. Supreme Court declined to hear the case and sent it back to a lower court so Google could argue that it made fair use of Oracle’s copyrighted APIs.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":1857259,"post_type":"story","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"bots,business,dev,mobile,","session":"A"}']

Is it just a coincidence that after all this back and forth, Google has decided to embrace OpenJDK? Unlikely, but the end result is what matters: Future versions of Android will be based on OpenJDK, not the implementation that Oracle currently has issue with.

Either way, the case isn’t over (Google can’t exactly change existing Android versions), and the final decision will still be watched very closely as it could have a huge impact on software development as a whole. If Oracle wins, tech giants could hold a lot of power over developers creating new software based on existing apps and services. If Google wins, fair use laws could essentially protect the use of APIs.

Update on December 30: Google followed up today to clarify some of the details the company explained to us before we wrote this article. As a result, the headline has been corrected to more accurately reflect the story. While Google is moving away from its own implementation (using Apache Harmony-based libraries) to use OpenJDK libraries as its foundation for the standard Java libraries, the company is still making changes to OpenJDK to make it work on Android. As a result, future versions of Android will continue to contain parts of Google’s “own implementation,” just based on OpenJDK.

Oracle declined to comment on this article.