This is my first blog post since leaving my role as Mozilla’s CTO 6 months ago. As you may have read in the press, a good chunk of the original Firefox OS founding team has moved on from mobile and we created a startup to work on some cool products and technologies for the Internet of Things. You’ll hear more about what we are up to next month.
While I am no longer working directly on mobile, a curious event got my attention: A commit appeared in the Android code base that indicates that Google is abandoning its own re-implementation of Java in favor of Oracle’s original Java implementation. I’ll try to explain why I think this is a huge change and will have far-reaching implications for Android and the Android ecosystem.
Why did Google create its own Java clone?
To run a Java app, you need a runtime library written in Java called the Java standard classes. This library implements basic language constructs like hash tables or strings.
Since the early days, Android didn’t use Sun’s version of the Java standard classes. Instead, the Android team enhanced the open source Apache Harmony Java standard libraries. Harmony is an independent “clean room” open-source implementation of the Java standard libraries maintained by the Apache Foundation.
There is basically no technical advantage in using Harmony. Its a strictly less complete and less correct version of Sun’s original implementation. Why did Android invest all this effort to duplicate Sun’s open source Java standard classes?
Apache vs GPL
Over the course of Android’s meteoric rise, the powers behind Android demonstrated a deep strategic understanding of different classes of open source licenses, their strength, and their weaknesses. Android has from its early days successfully used open source licenses to enable proprietary technology. Sounds counter-intuitive, but it explains why Google rewrote so much open technology for Android.
Java is actually not the only major open technology piece Google reinvented. Since Android 1.0 Google uses bionic as its standard C library. There were very few strong technical reasons to use bionic over open source alternatives such as the GNU libc. Quite to the contrary, at Mozilla in the earlier days of Android we had to constantly fight deficiencies in bionic in comparison to existing open source standard C libraries. Famously, bionic was not thread safe in many cases, crashing multi-threaded applications.
Writing a standard C library from scratch is crazy. Its one of the most commoditized pieces of software. Its almost impossible to do it significantly better than existing implementations, and it costs a ton of time and money and compatibility is a huge pain. Why did Google do it anyway? There is a simple answer: Licensing.
Bionic (as Google’s Java implementation) is licensed under the non-viral Apache 2 (APL) license. You 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. Its their competitive moat–their proprietary advantage. Google rewrote bionic — and Java standard classes — because silicon vendors and OEMs probably demanded that most parts of Android are open (ironic use of the word in this context) to this sort of proprietary approach.
Update: Bob Lee who worked for Google at the time commented below that OpenJDK didn’t exist yet when Android 1.0 launched (2007), so Google couldn’t use OpenJDK back then. GNU Classpath (LGPL) did exist since 2004, however. Google still chose Harmony, and stuck with it even after Apache abandoned the Harmony project in 2011. The switch now is clearly driven by the Oracle vs Google lawsuit.
“Open”JDK
OpenJDK is the name for Oracle’s Java that you can obtain under the GPL2, a viral open source license with strong protections. Any changes to OpenJDK have to be published as source code (except if you are Oracle).
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. What does this mean for Android?
In short: there is a new sheriff in town. The app ecosystem is at the heart of every mobile OS. Its what made Android and iOS successful, and its what made Firefox OS struggle. The app ecosystem rests on the app stack, in Android’s case Harmony in the past, and going forward OpenJDK. In other words, Oracle has now at least one hand at the steering wheel as well.
Its anyone’s guess what Oracle will do with it, but Google and Oracle have a long history of not getting along, so its going to be quite curious to watch. Java itself aims to be a platform, and it is similarly vast in scope as Android. Java includes its own user interface (UI) library Swing, for example. Google has of course its own Android UI framework. Swing will now sit on every Android phone, using up resources. Its unlikely that Oracle will try to force Google to actually use Swing, but Google has to make sure it works and is present and apps can use it. And, Oracle can easily force Google to include pretty much any other code or service that pleases Oracle. How about Java Push Notifications, specified and operated by Oracle? All Oracle has to do is add it to OpenJDK, and it will make its way into Android. Google is now on Oracle’s Hamster wheel.
A rough year ahead
In the short term Google’s biggest challenge will be to rip out Harmony and replace it with OpenJDK. They actually have been working on this for a while. It seems this project started in secret already 11 months ago, and is now being merged into the public repository.
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. Breakage will not be limited to correctness. Performance variances will be even harder to track down. Past performance workarounds will be obsolete but it will be hard to tell which ones, and entirely new performance problems will pop up. Fun.
And of course, licensing is changing as you can see here. The core of Android’s ecosystem runtime is now powered by GPL2 library code, copyright Oracle.
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.
The winner
No matter how you look at this, this is a huge victory for Oracle. Oracle never had much of a mobile game, and all the sudden Oracle gained a good amount of roadmap and technology influence over the most important mobile ecosystem by scale. Oracle is a mobile titan now. I didn’t see that one coming.
The losers
Google, and silicon vendors. The entire middle part of the Android stack will be subject to proprietary Oracle control. Google calls this “reduced fragmentation” in their press release. That’s true, kind of. There will be less fragmentation because Oracle will control anything Java, including Android.
Silicon vendors will be still allowed to do proprietary enhancements if they obtain the same library code under a difference (non-viral, non-GPL2) license from Oracle — for a fee. Oracle has actually already a history of up-selling OpenJDK. They are offering certain components of the Java VM only for royalty payments. You get a basic garbage collector for free. If you want the really good one, it’ll cost you. I expect Oracle to attempt to monetize in similar ways the billions of mobile users it just stumbled upon.
Andreas Gal 
I’m curious why you think this gives Oracle so much control over what Google puts in Android. Maybe you’re making some assumptions about some behind-closed-doors agreement that was made between the two companies? The way I see it, OpenJDK is really an open source (GPLv2) project that was forked from Sun’s Java pre-Oracle. I don’t even see how Oracle has much (if any) control over OpenJDK itself. Even if it did, what is to stop Google from simply forking OpenJDK if they don’t like the way things are going? There is nothing in any of the open source licenses (that I’m aware of) that would put Google in a bind. Obviously the GPL license requires that anyone that makes changes has to release them as well under the GPL but Google already does that for other portions of Android that are GPL’d.
The GPL2 is a fine license. Nothing wrong there. The problem is that Oracle has other ways to control Java, including the contributor agreement that assigns copyright to Oracle (which means that all of us have to adhere to the GPL2, except Oracle, which can extend/up-sell OpenJDK as they have done in the past). Oracle also owns the copyright and uses a different license for the TCK (compatibility suite). Last but not least, Oracle now also owns a valid claim over the Java APIs (see Oracle vs Google). So in essence the GPL2 allows you to safely use the code, but Java itself remains deeply under Oracle control.
You didn’t answer what the OP asked though. Why would google care what’s in OpenJDK (now, or added by Oracle, or anyone else for that matter) if they can fork it if they don’t like a feature? Google are only going to care about aspects of OpenJDK that they find useful. If Oracle adds Swing or whatever then would possible force could compel Google to add/not remove it?
Somebody just commented that swing was removed since the original commit (I didn’t have time to check yet). Whether Oracle will be able to leverage its lawsuit to control Java on Android remains to be seen. It’s clearly what they want. That’s why they spent years in court with Google. We will see whether Oracle succeeds.
“including the contributor agreement that assigns copyright to Oracle”
But there is no obligation to contribute any changes to Oracle, nor to openjdk upstream.
That depends. GPL doesn’t require that but Oracle has other means to push Google around. Google publicly stated that his will “reduce fragmentation”, which was Oracle’s main argument in their case. If Google forks now and diverges APIs again, Oracle would call foul in court. All depends. Will be curious to watch play out.
You do not address the option of Google not changing/diverging from APIs. As long as black box tests do not fail, I don’t think we can consider any change made by Google API-breaking.
Correct. And then Oracle adds an API and a test. And Google has to go along for the ride. The infamous hamster wheel and Google is on it. Oracle leads. Google follows. It’s pretty obviously Oracle’s plan. We will see whether they can pull it off or whether Google finds a way out.
Thanks for posting this. I think this is an important topic for the Android community to discuss. To get the ball rolling, I’ll play the devil’s advocate. I don’t see why adding support for OpenJDK would imply switching to OpenJDK. Android, for example, supports both the LLVM and GCC toolchains which has helped us understand the subtle differences between the two and improve both implementations. It also encourages users to write more standards-compliant code, which opens up opportunities to light up certain compiler optimizations (i.e. vectorized memcpy). Is it possible that the only reason we didn’t see OpenJDK support earlier is because Google was waiting on the outcome of their lawsuit with Oracle? Now that the courts decided Oracle owns the copyright on some of Harmany’s APIs, perhaps adding OpenJDK support to Android had no additional legal implications. Just a thought, IANAL.
Maybe. Only time will tell. But the code commits, Google’s press release, and Google’s court filings suggest this is a defensive move by Google, switching to Sun’s code under the GPL2, not adding OpenJDK as an option. Oracle successfully bullied Google into abandoning Harmony and only using Sun’s code going forward. My reading of the code commits anyway.
You’re right, not an added option but a complete switch. That’s a shame.
“Google’s Press Release”? Do you have a link to this? I haven’t seen anything…
http://venturebeat.com/2015/12/29/google-confirms-next-android-version-wont-use-oracles-proprietary-java-apis/
“Google’s press release?” Google put out a press release about OpenJDK? Do you have a link to this?
Several of the news articles quote a Google press response.
Google can still fork Android from OpenJDK and the only requirement is they just re-release it under GPL. If Google weren’t allergic to GPL there would be absolutely no issue here.
Yes. GPL is not bad. The fact that Oracle controls other aspects (trademark, TCK) and forces copyright assignments via OCA and uses lawsuits is the problem. We will see whether Oracle will allow Google to fork. The current lawsuit is just one way Oracle could try to stop Google from forking. Google is trying a different path now. Oracle doesn’t strike me as a company that will wise up and stop. This will get settled eventually, with Oracle getting its pound of Android flesh and I don’t think they are just after money.
If Oracle sued Google for forking GPL code, that would be extremely bizarre, and I’d like some confirmation that this is even possible. It doesn’t mean Oracle can’t act hamfisted, they have already lost control over OpenOffice, MySQL and Hudson, communities which went on successfully under different names.
Oracle clearly wants to control the Java ecosystem. We will see shortly how Oracle is responding to Google’s change.
Maybe I don’t fully understand the implications of this move, but how does Oracle control the stack? And why is Android forced to ship Swing? As it’s GPL2, they could strip it out and the only requirement would be to publish the changes, which they already do.
Right? … hopefully…
Only time will tell. But if APIs are (c) Oracle, Oracle can keep changing them, and can force you to keep implementing them. A hamster wheel. Someone commented Swing was removed again. Only time will tell whether Oracle succeeds forcing Google to follow, or whether Google gets away with a fork.
The Swing code was removed long before the OpenJDK commits were merged into the public repo:
https://android.googlesource.com/platform/libcore/+/785dbd9471a605e49bfa0c3f6f34644caf91303f
It seems very unlikely that Google would have to implement any hypothetical new services that get added to OpenJDK — they’re just making use of the standard libraries, not writing a JVM implementation that has to pass Oracle’s certification.
By using the Java standard libraries written by Oracle and released under an open-source licence, Google is seemingly trying to annul the complaint in the big lawsuit — that Google “copied APIs” from Oracle’s Java.
Yes, that’s my take on this as well. Pretty sure Google isn’t doing anything so grand-scale as the article implies – they’re simply replacing their own (Harmony-based) implementations of some of the Java APIs with ones from OpenJDK – and they have several good reasons for doing so.
On a technical level, it reduces the amount of code they’re having to maintain unnecessarily, and it reduces potential incompatibility between Java-proper and Java/Android. And on a legal level, it protects them – for all that the API copyright ruling was an absurd outcome, the use of Harmony was a liability that doesn’t exist if they use Oracle’s own GPL-licensed code.
I don’t think the technical arguments hold. Google doesn’t care about Java compatibility. To the contrary. Google probably prefers to be incompatible. Google has much more and more valuable users on Google Java than Oracle. I agree with less maintenance and patent grants but these come at a price: Oracle control.
Actually, Android used Harmony because OpenJDK didn’t exist yet. As Android’s first core library lead, I personally integrated Harmony into Android, and I’m ecstatic to see Android and OpenJDK share the same library code. This will greatly simplify contributing enhancements.
So Google filing a declaration in Oracle vs Google that it’s switching to OpenJDK a few days after the patches that Google worked on for 11 month in secret were pushed is just a big old coincidence? This has nothing to do with the lawsuit? :)
I can’t speak to the current developments—I left Google 6 years ago. But your core premise is wrong. We chose Harmony simply because OpenJDK didn’t exist yet.
I’ll update the text when I am at a keyboard. Thanks! Maybe we can agree that Google stuck with Harmony and didn’t use OpenJDK or Classpath because of the license.
Sorry, I can’t imagine how the license would create an issue in this context. Android uses the Linux kernel which is GPL and there’s no issue there. At most, Android vendors will have to open source any changes they make—like they do with the kernel—but I doubt that any of them actually make changes to the core libraries.
Now this is definitely incorrect, based on first hand conversations and observations. First of all, many Chinese OEMs habitually fail to open source Kernel changes, and second, silicon vendors and OEMs both shy away from GPL as much as they can because they don’t want to open source their changes. It took us many months to make them comfortable with the MPL for parts of Firefox OS, and the MPL isn’t as viral as the GPL (per file, not per code base). Google went to great length to avoid GPL code, and rewrote things like libc and the Bluetooth stack to keep core Android open for proprietary extensions. Silicon vendors often mess around in this code (most of the time not very successfully, but thats a different story). Just compare Qualcomm’s Code Aurora repos with Google’s original release.
This probably is related to the lawsuit, but I would imagine that phone vendors aren’t making proprietary changes to the Java standard libraries, so presumably OpenJDK being GPL isn’t a big concern.
I haven’t personally seen a lot of valuable silicon vendor proprietary changes to Android in general, but it seems very important to them and they emphasize to their OEM customers that they make them. It’s their value add and business model.
OEM here. 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.
I wondered, why Google has chosen Java in the first placed. Why not, say, Python?
Did you have those considerations back then, Mr. Lee?
IANAL.
I remember there is another issue about OpenJDK than licences: patents. Basically you have the right (a patent grant) to use Java only as long as you use OpenJDK. Using Harmony is a legal risk to Google. According to Wikipedia [1] Oracle is quite in a position to win the lawsuit. Couldn’t this be the real cause for this change?
[1] https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc.
Absolutely.
You don’t seem to understand the difference between JVM and Java API. Google will use the Java API on Android but won’t use the JVM (No Hotspot). Android uses ART, ahead of time compilation, so no problem with what you call “Proprietary garbage collection ” algorithms…
That was just an example how Oracle can take advantage of the fact that everyone can only use OpenJDK under the GPL, except for Oracle. Oracle owns all the copyright and can offer proprietary extensions. That applies to the libraries as well as the VM.
When Android includes the complete expected behaviour of the OpenJDK, at least Oracle will be able to easily produce versions of Android which include also other stuff such as Swing, JavaFX or any proprietary extension. One may for example fancy about an Android embedded into a JavaEE engine or whatnot.
Maybe with this the normal app devs will get Java 8 features sooner?
Yeah that’s very likely (and what Oracle wants too, keep the ecosystem in lockstep).
Andreas,
I’m curious to know what you think about Microsoft’s efforts with Windows 10 in terms of IoT edition and their support for Docker and other opensource contributions… and in particular if it’s something you’re looking at for your own IoT efforts and how that app model might extend as an alternative to Oracle-controlled mobile, since the universal apps would let you run on IoT, mobile, and beyond.
I’ll talk about our vision for IoT in a few weeks. Stay tuned :)
I wrote a response of sorts to this on my blog: http://ebb.org/bkuhn/blog/2016/01/05/jdk-in-android.html
I read your writeup. I think we agree on the core observation that Oracle is a really poor stuart of open source projects and is using the GPL2 as a weapon, not as a tool to create a great, open, participatory project. Google is going to acutely feel being on the receiving end of that because Oracle will start asserting some degree of control over Android’s technology roadmap (or well at least try). We can disagree on how this will affect the rest of the industry. I don’t think that part matters as much. And keep in mind. I have no stake in this. As far as I am concerned this couldn’t happen to two nicer companies. Oracle and Google deserve each other. They both use their respective tricks to lock in customers into their ecosystem.
Pingback: It looks like Google finally caved in to Oracle’s copyright claim over Android | On Reddit
Google should now join Java Executive Committee. Java 8 has compact profiles which doesn’t include Swing, and even if any of these profiles is pefrectly suitable to Android, there is Java 9 coming where you can leave what you want. I believe this is win-win-win decision for Oracle, Google and me- as a developer.
For Oracle- because as you said they have their claws into android
For Google- they are now maintaining own Java and contributing to OpenJDK anyway, so having one Java is better for everyone.
For me- as above
« Swing will now sit on every Android phone, using up resources. »
Yeah, no :) Using (a fork of) OpenJDK doesn’t mean you must use and ship all of OpenJDK. That’s simply not how the GPL works!
Yes. And no. Oracle isn’t just using the GPL here. Oracle controls Java via trademarks, test suites, existing agreements, and now also API copyrights. If this was a simple issue of licensing Google would still be using Harmony :)
I guess Google’s plan is to argue that the terms of the GPL apply, and are sufficient for them to use OpenJDK. Oracle will say that no, other terms also apply.
The court will have to decide.
In my opinion, Google is at a better position now, with this change, to argue that Oracle actually allows them to use Java. It was less obvious before, with Harmony.
I believe there is also a true technical motivation here, it is not just a “legal” change. It is easier for Google to rely on OpenJDK to get new features, than to have to re-implement them themselves! I mean this is a huge task!
Of course it is also a huge one-time task to make this change, but it will pay off in the future.
classpath exception? No word about it in the article…
http://openjdk.java.net/legal/gplv2+ce.html
Thus, app developers are no target.
I agree. App developers will not be affected by the licensing change. They will be affected by correctness and performance breakage, however.
How can you copyright an API? You can copyright its description, sure, but the API itself? That makes no sense. You might as well copyright the tip of a screwdriver.
I agree with you. The SCOTUS doesn’t. Not sure what else I can say.
Inactive member of bar here :-).
Tips of screw drivers are not “written down”. APIs are “in writing”.
Copyright prevents u from “copying” things others have “written down”. It is not the idea, substance, etc that is protected/prevented. Its the copying in writing. Over simplication yes, but that is the gist. The trial court decision was the surprise legally speaking, not the appellate reversal.
A while back I saw the Flutter System Architecture from Google. Don’t remember all the details. Dart is pretty useless as Google envisioned it (as an alternative to JS). But it is a good language designed for a wrong purpose. It is close to C# – so wouldn’t it be better for Google to invest into Dart (to make it more general purpose language) and make it a first class citizen on Android platform (outside of browser). While they are at it, they should look at interfacing with native code a better mechanism than JNI. I think Dart will be a better alternative to Java, without the challenges from Oracle. Granted it will take time for Java Developers to switch, but if the platform is rich enough, they would. Swift is a great example of that!
I think you are right on and there is a good chance this is Google’s long term plan.
Have you considered these points.
1) The OpenJDK license has a class-path exception with provides a mechanism for application developers to protect their intellectual property. When one changes the Java platform code they are bound to sharing the modifications with the community (no free ride).
2) Java 8 defined configuration profiles which allow for implementing less than the whole platform (ex. no SWING). Perhaps, Android will take of advantage of this new capability
3) A significant benefit of technology alignment between the two firms is the larger ecosystem. Decreased platform fragmentation, platform fidelity across vendor implementations benefits all application developers who almost universally want to target the broadest addressable market for their solution.
Hopefully Google will contribute resources to OpenJDK and provide implementation features (GC, ARM) that benefit the ecosystem and expedite propelling the OpenJDK platform past Oracle’s objective as a reference implementation for the JCP specifciation.
I don’t think anyone disagrees with 1). Apps won’t be affected by the license change.
2) is a good point and someone else comment on this as well. I agree this will be interesting. Oracle can still stick proprietary extensions in places that aren’t optional though. We will see!
As for 3), Java is pretty much dead except on the server. Android is mobile Java. I don’t think this helps fragmentation significantly. Android’s own API versioning and the lack of updates fragment mobile. Newer language features are one upside of this.
I hope Google’s decision is not to just leverage OpenJDK but to contribute to OpenJDK. Their contribution can offer innovation to the community that Oracle will not address. The broader Java and Android ecosystems will benefit from alignment on OpenJDK. Note that IBM also moved from Harmony in favor of OpenJDK.
Google announced they will contribute to OpenJDK, which is a strong indicator that Google doesn’t intend to fork and will follow Oracle’s lead.
Funny to see Google concerned about Java fragmentation now, after Sun Microsystems is no longer with us. Google could have chosen to license Java from Sun as have IBM and others and share its wealth a bit. Google contributed to Sun’s demise and deserves everything it’s getting from Oracle.
And on this topic of demise, it’s Google’s partly-proprietary Chrome web browser that’s significantly cut into Mozilla’s Firefox web browser market share, rather than it’s purely open-source Chromium web browser.
While Google is a heavy user of open source software, it’s not friend to open source IMO.
Finally, don’t forget that Oracle got IBM to abandon its support of Apache Harmony with an offer of increased control over Java, including OpenJDK (although not as much control as Oracle wields). This isolated Google as the sole corporate user and “maintainer” of its fork of Harmony.
Great Post Andreas! I really enjoyed your article and your paragraph on why bionic was created reminded me of my old days in Android platform development work. I remember trying to certain frameworks and applications running that, historically were on Linux, and were being ported to Android and depended on certain libc functions that were either commented out or missing in bionic!
It will be interesting, especially from where I am sitting, to see how Oracle influences current versions of Android and what other parties, in conjunction with Oracle will do.