We distill here some of the reactions around the web regarding Google’s adoption of OpenJDK for future Android versions.
We wrote at the end of last year that Google decided to replace the Harmony implementation of the Java libraries used in Android with OpenJDK. (The details can be found here.) In spite of the announcement coming around Christmas time, Google’s decision triggered some reactions around the web, some of which we would like to summarize here.
Google’s decision to switch to OpenJDK can be traced in code back at least to February 2015 according to this Git ticket. The code commit that brought this issue under the media’s scrutiny in December includes an important license change. The new Java libraries for Android N are no longer to be licensed under Apache License 2.0 (APL), but under GNU GPL 2, and the copyright notice includes the following statement: “Copyright (c) 1997, 2011, Oracle and/or its affiliates. All rights reserved.”
Andreas Gal, former CTO at Mozilla, wrote a post emphatically entitled “Oracle Sinks Its Claws into Android,” arguing that Google has tried for a long time to use Harmony and the Apache license because one
can use and modify APL code without having to publish the changes. In other words, you can make proprietary changes and improvements. This is not possible with the GNU libc, which is under the LGPL. I am pretty sure I know why Google thought that this is important, because as part of launching Firefox OS I talked to many of the same chipset vendors and OEMs that Google works with. Silicon vendors and OEMs like to differentiate at the software level, trying to improve Android code all over the stack. Especially silicon vendors often modify library code to take advantage of their proprietary silicon, and they don’t want to share these changes with the world. It’s their competitive moat – their proprietary advantage.
Commenting on Gal’s post, Bob Ross, who describes himself as an employee of an OEM, nuanced a bit the APL vs. GPL issue:
We do make changes to libcore. The problem with open sourcing in this case would be the tremendous overhead, not the secrecy, at least for the changes I’ve been a part of.
Bradley M. Kuhn, currently President of Software Freedom Conservancy and Member of the Board of Directors of the Free Software Foundation, has a different take on how GPL might affect Android development. In a recent post, “Sun, Oracle, Android, Google and JDK Copyleft FUD,” Kuhn draws attention to the fact that OpenJDK is licensed under an “extremely weak” license, GNU plus the Classpath exception. Kuhn was involved in designing and naming the Classpath exception which was meant to avoid “infecting” the whole Java ecosystem with a copyleft protection that would force all Java programs to be free to use and redistribute. And that makes using OpenJDK not much different than Harmony from a license perspective, according to Kuhn:
So, how is incorporating Oracle's GPL-plus-Classpath-exception'd JDK different from having an Apache-licensed Java userspace? It's not that much different! Android redistributors already have strong copyleft obligations in kernel space, and, remember that Webkit is LGPL'd; there's also already weak copyleft compliance obligations floating around Android, too. So, if a redistributor is already meeting those, it's not much more work to meet the even weaker requirements now added to the incorporated JDK code.
But Gal considers that Oracle now has an important influence regarding the future of Android not just because of the license but through the Java roadmap, trademarks, agreements, patents:
Because Oracle has means to control Java beyond source code, OpenJDK is about as open as a prison. You can vote on how high the walls are, and you can even help build the walls, but if you are ever forced to walk into it, Oracle alone will decided when and whether you can leave. Oracle owns much of the roadmap of OpenJDK, and via compatibility requirements, trademarks, existing agreements, and API copyright lawsuits (Oracle vs Google) Oracle is pretty much in full control where OpenJDK is headed.
Several readers commented on Gal’s post saying that if Oracle does not play nice with OpenJDK, nothing stops Google to fork it, and directing the development the way they want.
Gal also predicts a “rough year ahead” for Android:
All this code and technology churn will have massive implications for Android at a tactical level. Literally millions of lines of code are changing, and the new OpenJDK implementation will often have subtly different correctness or performance behavior than the Harmony code Google used previously. Here you can see Google updating a test for a specific boundary condition in date handling. Harmony had a different behavior than Oracle’s OpenJDK, and the test had to be fixed.
The app ecosystem runs on top of these shifting sands. The Android app store has millions of apps that rely on the Java standard classes, and just as tests have to be fixed, apps will randomly break due to the subtle changes the OpenJDK transition brings….
I also have a very hard time imagining Android N coming out on time with this magnitude of change happening behind the scenes. Google is changing engines mid-flight. The top priority will be to not crash. They won’t have much time to worry about arriving on schedule.
Brendan Eich supported Gal’s opinion in a tweet: “We don't know enough yet, but I agree with @andreasgal that code changes show cost+risk go up.”
Shai Almog, cofounder of Codename One, agreed that indeed there is some work ahead for Google and Android developers, but not nearly as much as Gal and Eich suggest, and there are some benefits coming from using OpenJDK:
While there are some changes that benefit users directly, most software development changes don't. Not all developers benefit from every language/API feature either.
Users will benefit from the fact that code bases are unified and security auditing will now focus on a more uniform code base. A lot of the standard Java tools might work better with Android as a result….
Yes this will take Google some effort. Yes a few apps might be affected, I'd wager this would be far less than those affected by the Marshmallow changes and Google has the tools to alleviate a lot of that problems (sdk version hints).
Some have wondered if Google’s adoption of the OpenJDK has something to do with the lawsuit they have with Oracle. Kuhn believes that behind Google’s decision are technical reasons:
A Java industry analyst (with more than a decade of experience in the area) told me that he believed the decision was primarily technical. Authors of userspace applications on Android (apparently) seek a newer Java language implementation and given that there was a reasonably licensed Free Software one available, Google made a technical switch to the superior codebase, as it gives API users technically what they want while also reducing maintenance burden. This seems very reasonable. While it's less shocking than what the pundits say, technical reasons probably were the primary impetus.
It is perhaps too early to fully evaluate the implications of Android using OpenJDK for future versions of the operating system. It depends much on Oracle and the ongoing lawsuit with Google. It is not yet clear if an API interface is copyrightable or not, and the law and the courts will have to clarify that. Parts of Android, both Java and C code, have been rebuilt starting from previous existing libraries and deleting the code but maintaining the interface or the header files. Is Android trouble free? It remains to be seen. Adopting the OpenJDK should alleviate some of the issues, Google now having Java license coverage and patents grants to protect Android from Oracle.