Musings on Android and the OpenJDK
In case you missed it, Google is replacing the java.* and
javax.* classes in the Android SDK for the next major Android
release (“N”, presumably with a tasty treat of “N’oreo”).
The editions of those classes in the Android SDK today originated
with Harmony, Apache’s initiative to create an Apache-licensed
Java-compatible class library and runtime environment. The new
editions come from OpenJDK,
the open source edition of Java from Oracle.
The OpenJDK is licensed under a license known as “GPL with Classpath exception”. I am not going to get into the details of that — I’ll let Bradley Kuhn handle that, as he knows much more about it than I do.
Similarly, I’m not looking to hash over what this means for the Oracle v. Google lawsuit, much of which stemmed around those Harmony-based classes.
Instead, I want to focus on what this will mean for you as an app developer.
In short: probably not much.
Some will see the “GPL” in “GPL with Classpath exception” and panic that their apps will somehow need to be GPL-licensed. That’s not how that license is generally interpreted, as the “Classpath exception” limits the GPL copyleft effect with respect to code that merely references “GPL with Classpath exception” via Java-style classpaths.
The biggest worry is compatibility. There’s a lot of code in java.*
and javax.* in Android. While the Java TCK is extensive, I have little
doubt that there are gaps there, just due to sheer size. It is entirely
possible that we will have to deal with some quirks, where Android
Java classes departed in behavior from standard Java and now wind up
back in compliance with standard Java. These should be fairly few and
far between, as Google is pretty good about maintaining backwards
compatibility. But, again, just due to the size of the code base, I will
be stunned if Google can pull of the switch perfectly. So, there will
likely be a few more Build.VERSION.SDK_INT checks we will need to
work around those issues.
The oft-cited benefit of this move is to make it easier for Android to adopt more Java 8 language features, such as lambdas. Moving to the OpenJDK probably will make it easier for the tools team to start supporting Java 8 features. However, it will be 4+ years before OpenJDK-based Android OS versions become 90+% of the Android device ecosystem, particularly since we’re probably the better part of a year away (if not more) from Android N shipping. What we may see is a rise in interest in Retrolambda to help fill the gap, with lambdas becoming more default in Android app development. Regardless, all of this should be “opt-in”, meaning that you have more options but do not have to worry about them when N ships if you do not want to.
Personally, I am hoping for greater clarity on what Google’s intentions
are with respect to the java.* and javax.* packages that they are not
including in Android N. From the beginning, we have had nasty compiler
errors if we try including java.* or javax.* packages in our apps,
pointing out that if Google elects to add support for those packages to
future editions of the Android SDK, the SDK’s edition of those packages
will be used instead of our app’s edition of those packages, and if
there are incompatibilities, we’re screwed. But given that Google is
having to do a top-to-bottom analysis of OpenJDK and determining what
they are and are not going to use in Android, I am hoping that they will
document:
-
the packages they are using (in this case, this falls out of publishing the N JavaDocs)
-
the packages that they reserve the right to add in the future (today, that’s everything)
-
the packages that they aren’t going to touch with a 3.048-meter pole
Ideally, the latter group would represent packages that the community can experiment with adding to apps via independent libraries. While many Java packages that Google skips will not be especially relevant for Android (e.g., Swing), others have had long-standing interest from the developer community (e.g., JAX-RPC). But, once again, this should only open up new opportunities, not harm developers’ existing code bases.
There may be yet further impacts, beyond what I have outlined here, that affect ordinary app developers. Certainly, the switch to OpenJDK will make Android N somewhat more interesting than your average Android OS release. There does not appear to be anything you need to be worrying about in advance, but, as usual, once a developer preview of Android N ships, try your apps on it and see how they hold up.
