Over the holidays, eagle eyed devs spotted a pretty portentous commit to the Android codebase, which signalled that all future Android Builds will be using OpenJDK’s core libraries. Up until now, Google has been utilising a class library derived from Java implementation Apache Harmony.

Whilst the news has subsequently been confirmed by Google, for now, Oracle is keeping tight lipped on the matter. Although the revelation that Google would be using a fully open source brew of Java was initially taken as a sign that the long-running lawsuit  around the fair use of APIs between the two tech titans had been settled out of court, papers filed on December 24th seem to indicate that this is not the case.

What’s going on in terms of respective thrust and parry between Oracle and Google’s legal squads is anyone’s guess, but in terms of technical implications, this move will certainly help to shrink the void between “pure” Java and Android applications.  

Gluon co-founder Johan Vos believes that from Android N onwards, life will be a lot easier for devs, who will gain the freedom to use standard Java classes the same way they use those classes in “pure” Java environments.

He comments; “Once the Java class library available on Android systems is the one from OpenJDK, this means the standard Java APIs can be used. That means Streams will work, and all the Java 8 APIs (and Java 9, in the future) are available. At this moment, Android developers have to be careful when using Java APIs, as not all classes that are part of Java SE 8 are on the platform, and some classes are lacking methods that should be available.

If you look at Android questions on StackOverflow, those are often about Java libraries that are not working on Android. Most of the time, the reason for this is that the library uses some core Java class that is not available or incomplete on Android. Once the OpenJDK solution is integrated, those libraries should work out of the box.”

On a personal note, for Vos, there are a couple of direct impacts from Google’s shift in strategy.

Previously, he explains, there were two key prerequisites for porting JavaFX to Android:

  1. Making sure the OpenJFX source code is not using Java SE APIs that are not available on Android, and writing workarounds for the places where this could not be avoided.
  2. Porting the native rendering code to the Android native platform.

“The first part will now be redundant. That means we don’t have to spend resources on it anymore, and our focus can go to the second part. As a consequence, the technical quality will get better.”

Moreover, there is an important strategic impact. “JavaFX is the standard for Java on the Client. It is the standard way to create User Interfaces in Java. Now that Android is moving into the direction of standard Java, the step towards using the JavaFX UI platform becomes much smaller. OpenJDK and OpenJFX are very well aligned with each other. Actually, OpenJFX (which contains the source code for JavaFX) is the best integrated UI framework for OpenJDK.

This does not mean that there is no room for Android APIs, at the contrary. But it might be a smart move for Android to focus on device specific functionality and e.g. the Google Play services, and have the “standard” functionality and UI left to OpenJDK and OpenJFX.”

Vos also notes that with around 9 million Java developers currently at large, the shift to OpenJDK paves the way for more development on Android, more supported third-party libraries, and more and better apps. So far, the omens in this respect are positive. In a statement to Venturebeat, Google writes that it 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.”

Currently, Android devs have been forced to make do with Android 6, which sits nearly a decade behind Java 8. The release of the latter has stimulated a continued uptick of interest in Java over the past two years, largely thanks to the functional goodies and other enhancements it brought to the table. Vos envisions a similar bump in enthusiasm for the language from the wider Android community now that the gates have been thrown open for mobile coders to embrace “modern paradigms.”