How Android's Adoption of OpenJDK Will Affect Developers

Android's Java: From Custom Software to Open Source

In late December 2015, VentureBeat reported on a set of commits to the open source Android codebase. Google confirmed that the development team was replacing Android's custom Java libraries with equivalent implementations from OpenJDK, the open source version of Java that’s maintained primarily by Oracle and that contains nearly all of the code used in Oracle’s commercial release. Google also let it be known that this change would be part of the next major Android release, currently known as Android N.

A flurry of reports in trade press and individual blogs shortly followed, some of them a bit alarmist. It’s been nearly a month since the initial news came out. In this post I’ll review what we know about the coming change, and how it might affect Android app developers.

Android, Java, and Apache Harmony

First, a bit of history. Java was selected as Android's primary app development language because of a combination of its popularity and its portability. Android works on a variety of CPUs. To make an app easily distributable to all of Android's supported platforms, its packaged code couldn't already be compiled to hardware-specific machine language. A language that compiled to cross-platform bytecode was needed. That eliminated C, C++ and other compiled languages. But Java was originally designed with this sort of portability in mind. The language's original slogan was "Write once, run anywhere".

Android doesn't host a complete Java runtime, and doesn't work directly with the bytecode produced by the 'javac' compiler. And so another form of bytecode known as Dalvik Executable (DEX) format is produced and included as part of the packaged app. That code then goes through a last stage of compilation on the user's device to native machine code. Android's original Dalvik runtime does this last step just-in-time (JIT), as the app is running. The newer ART runtime, on Android 4.4 and later, compiles ahead-of-time (AOT) upon app installation or upgrade. Either way, at runtime the device is running lower level code that's specific to that device's hardware.

But app developers mostly don't have to worry about this. They program using Java's well-defined class libraries, which have application programming interfaces (APIs) that define the names of classes, interfaces, methods, and other programming elements. Those APIs are part of what defines Java, but they aren't the whole picture. The API says, for example, that to create a string value you use Java's String class. Here's one way to do this:

String myString = new String("Hello from Android!");

That statement always does the same thing, creating and initializing a string value, regardless of whether it’s part of an Android app, a desktop application built with AWT, Swing or JavaFX, or a web application running on a Java Enterprise Edition (JEE) server. But the code that’s actually executed by the hardware is provided by the implementation of the String class and any other classes on which it depends. Oracle’s implementation of those classes, organized into class libraries, can be different from the implementation in current versions of Android.

Android's current implementation of Java’s class libraries is based on Apache Harmony, an open source product from the Apache Foundation that was retired in 2012, rather than Sun Microsystems' original codebase. And that divergence is what led eventually to the ongoing legal battle between Google and Oracle over the use of Java in Android.

The details of that lawsuit are well covered elsewhere, and as the only member of my immediate family who isn’t a lawyer (really) I’m not qualified to comment on its merits or status. As an Android developer and educator, my primary concern is in how the upcoming change might affect all those who create apps for Android devices. Here are some frequently asked questions about what’s coming in Android N, and my own take on how it might change things.

How much of this is because of the lawsuit?

OK, fine, here’s what I’ve read. According to Google, the change to OpenJDK is mainly intended to provide better support to developers and leverage the work of the open source community. Also, Google is a contributor to OpenJDK, and it makes sense for them to focus their resources on a single implementation of the Java language and class libraries. It’s worth mentioning, however, that in December Google filed notice with the court of the coming change. So it probably has something to do with the lawsuit. How much, only Google knows.

By moving to OpenJDK, Android should be able to upgrade its Java implementation more quickly in the future to support new language and library features.

I don’t care about the lawsuit. Are Android's APIs going to change?

In regard to Java packages that start with ‘java’ and ‘javax’, the answer is: Not in any significant way.

An API is the public-facing aspect of any code library. It defines how the library’s classes and methods are called, not the mechanics that happen in the background. The object oriented programming (OOP) concept of encapsulation means that the app developer says what will happen when they call the API, but the library’s implementation determines how the work gets done.

Even though Google’s implementation has diverged from Apache Harmony, which in turn was built as a clean room implementation without reference to Sun’s original code, the Android development team has carefully maintained compatibility with Java SE's API specifications. Java libraries are designed to be pluggable. If they implement the same package, class and interface names, and all of the same method signatures, you should be able to replace one implementation with another and everything will still work. It would have been counter-productive for Google to change the original APIs, so their version still matches Oracle's, class-for-class and method-for-method.

So my apps will work perfectly on Android N without any changes?

I, and all Android developers, sure hope so. But this shouldn't be minimized. The implementations aren’t the same, and this is a big engineering change. In an ideal world (one that software developers seldom occupy), everyone’s app will do exactly what it did before, and will be faster, better and more reliable! In the real world, you should plan for extensive testing before you deploy an app that targets and is compiled with Android N. But that’s nothing new. Any time you upgrade your software to support a new version of an operating system, you should already be testing, testing, and testing again. You can prepare now by investing in test-driven development strategies, and building automated tests for your app's business logic and user interface.

What benefits will Android developers see?

By moving to OpenJDK, Android should be able to upgrade its Java implementation more quickly in the future to support new language and library features.

Prior to this change, when Oracle's Java added new syntax and libraries, at minimum it took a long time for Android to catch up. For example, Java SE 7 was released in July of 2011. Android only added support for (most of) Java 7's new syntax features in late 2013 with the introduction of Android 4.4 KitKat. And Java SE 8's newest syntax features that were released in early 2014, including lambda expressions and method references, still aren't supported in Android today.

After adopting OpenJDK, Android's support for future improvements in Java might come about more quickly. The Android team will be able to start with Oracle’s improvements that are delivered as open source, and they won’t have to re-implement those new features from scratch.

Is this a good thing for Android and/or Java?

It looks good for everyone. No one has been well served by Android’s delays in implementing new Java features. Focusing both Oracle’s and Google’s resources on a single Java implementation could help speed delivery of future new versions. And a resolution of the legal battle would remove the dark cloud that’s been hanging over Android developers for the last few years.

The bottom line

Google hasn’t announced when Android N will be launched or released, much less what its sweet snack code name will be. (I’m betting on Nougat; feel free to add your nominations in the comments.) But when it arrives, Android developers will finally be working with the same implementation of Java’s class libraries that the rest of the Java community uses. Hopefully, the change won’t be too painful. And the potential benefits are great.