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.
