I am not sure how enforceable those restrictions were, but I imagine that factored into the decision to use the Apache JDK project
In any case, OpenJDK was released in May 2007, and Android unveiled in November later that year and made available only a year later. The reason Google used Apache Harmony was because they couldn't reach a licensing agreement with Sun and chose not to use OpenJDK because of its GPL license, believing phone vendors would reject it.
As Google probably wanted to have a non-standard edition of Java, it's unlikely that Sun would have licensed it to them (or they would have required a new standard being formalized first). Their best option was to use OpenJDK, but they didn't. They wrote their own runtime -- which, to this day, is at a great performance disadvantage compared to OpenJDK -- suffers annoying incompatibilities and is a few Java versions behind, all in order to not use GPL software.
Was Google right in thinking that phone manufacturers not have put up with GPL? I'm sure that at the time that's what the phone makers told them. Perhaps Android wouldn't have taken off if they had tried to shove the GPL down their throats. But I believe that with the iPhone breathing down their necks and no better alternative, the phone vendors would have yielded. We would have ended up not only with a much better, faster, more compatible Android, but with the most ubiquitous operating system on the planet being truly free. This also would have prevented the Oracle-Google lawsuit.
Instead, we're left with a slow OS that's years behind embedded Java, not truly open (as closed-source modifications are made by vendors), and a legal battle that some believe may have far-reaching consequences. All because people are afraid of the GPL.
[1]: For example, I believe (though I'm not sure) that IBM's and Aicas's JDKs follow the first choice (maybe the second), Azul's Zing JVM the second, and Azul's Zulu the third.
This is completely incorrect. OpenJDK is absolutely not optimized for mobile and it would have been a disaster on mobile. A lot of the Dalvik runtime and libraries have been rewritten with performance and memory in mind.
You are right that Dalvik was written to be optimized for mobile, but you have to understand compared to what. Dalvik is optimized for mobile compared to simple VMs that don't have a lot of work put into them -- not compared to HotSpot. Java's embedded versions have had a lot more effort put into them than Dalvik.
Dalvik itself was plan B for Google, after they'd failed to secure a licensing deal with Sun (and didn't want OpenJDK's GPL). It wasn't anyone's first choice, and certainly wasn't some new powerful technology. Just a VM that was good enough compared to the effort that's been put into it.
There are open source (obviously) OpenJDK distributions[1] specifically made for embedded devices (although you can build them yourself), and (proprietary) editions of Java have been running on devices as constrained as SIM cards for much longer than Android exists.
This aspect and the Dalvik bytecode are the main reasons why Dalvik is so fast on mobile. No other VM (or JVM) can realistically compete, especially not HotSpot. Not now and certainly not back then.
Making HotSpot multi-process would have been a much smaller effort for Google. It really isn't that hard.
> No other VM (or JVM) can realistically compete, especially not HotSpot. Not now and certainly not back then.
I've just shown you how HotSpot embedded handily beats Dalvik. Remember, Dalvik was Google's plan B. It wasn't anyone's first choice, and certainly not some cool groundbreaking technology. It's a not-too-shabby VM for the amount of effort put into it (which isn't much), and it was available for Google to buy. That's all.
Your budget determines the kind of software you get. On a purely engineering basis, Hotspot might have been the better option, Business-wise, Dalvik made sense to Google.
1. http://www.pcworld.com/article/253666/a_timeline_of_oracles_...
* March 2007 -- Sun open sources the JDK at the perfect moment for Google to adopt it. Google chooses not to because they don't like the GPL.
I think the phone vendors would have caved. It might have taken another year, but they would have realized they had no choice once the app store opened in July 2008, as none of them could have had the brand recognition to build an attractive software platform to rival the iPhone.
Do you think Sony, let alone Verizon would cave and agree to the terms of the GPL? Remember this is in 2008 - Sony's DRM/rootkit scandal was only 3 years prior (2005).
Edited: fixed my years
Also, just to clarify, the pill really isn't all too bitter. Use of OpenJDK wouldn't have dictated that all apps must be GPL -- not even bundled apps made by the manufacturer. The OpenJDK has a clear "classpath exception", which makes it more like LGPL -- any code dynamically linked with it is not required to be GPL. The only implication is that any modification they make to the actual runtime itself would have needed to be GPLed. I don't think phone manufacturers make any technologically groundbreaking, game-changing changes to the runtime -- anything that could hurt their competitiveness had it been free.
So I can understand Google's decision, and they certainly believed going GPL was an opportunity cost, but in retrospect, choosing OpenJDK would have -- at the very worst -- delayed Android's adoption by a single year, but would have ended making everyone's life much easier. I think that in hindsight, it's clear that passing on OpenJDK was a big mistake. Don't fear the GPL.
http://www.atego.com/products/atego-perc/
Just one example.
Google won round one..... Lost round two on appeal .... And is now appealing the lose.
To make that claim, you will have to show another mobile JVM-based OS that's faster than Android.
Used in missile radar control stations and battleship weapons systems.
Is that fast enough for you?
If Android had been using the GPL, it would probably never have taken off because:
- Manufacturers and other partners would have refused to use it
- OpenJDK is not optimized for mobile, so performance would have been disastrous (especially in 2007, try to remember the kind of phones we were using back then)