I was following the goings on between the ASF and Sun/Oracle a while back, but I was un-aware that ASF and google also had problems! What was the nature of their disagreement?
I think lambdas is the one killer feature I would love to see in Android/Java - particularly for a framework such as Androids which is so callback heavy, lambdas would be an immense help.
It's not really a feud thing, but they did go and use the now abandoned Apache Harmony code instead of just working with Apache on OpenJDK and working out an appropriate license for Java through them (and probably avoided the Oracle legal mess). I can't speak for either side, but I never pictured Apache as being overly happy about Google's choices in that situation. Someone who is more of an expert (as I'm not) on the events behind this can probably give a more accurate interpretation.
OpenJDK has a field of use restriction; sublicensing it to remove the field of use restriction would have been illegal. Google would have had to license it from Oracle without the restriction.
Given huge effort to implement Dalvik in such a way that the end result could not be called Java, they had to be able to make the argument that Dalvik was a cleanroom implementation of Java. They worked from open specifications; Java 6's specification was open-source, whereas Java 7+ was locked down. There is no Java 7 implementation that could be made without violating the license terms of the specification, as it was no longer open.
It's also clear that they could never have worked with Apache, as any developers who had seen substantial Java 7 implementation code or the specification could be considered "contaminated", and thus any work on Dalvik or any other non-FOU-restricted JVM could be in violation of the license terms. Whether or not this would actually be true, it would be a huge, huge legal vulnerability.
Google and Apache had to avoid each other out of legal necessity to ensure Dalvik's survival. Oracle v. Google could never have worked had they not implemented a very strict (and well-implemented, albeit slightly imperfect) isolation between "Android Java" and "Actual Java". Android technically can't (and doesn't) call what runs on Android devices "Java" - because it's not a compliant VM, they don't have the trademark to use it as such. That said, because of the process they use in which the code is compiled to Java bytecode before it's compiled to Dalvik bytecode, they can make reference to it in terms of the tools - just not in terms of Android actually running it.
OpenJDK does not have a field of use restriction; if it did, Linux distributions would not ship it as Open Source software (it wouldn't appear in Debian main, for instance).
The Java compatibility test suite does have some such restrictions, but those same restrictions would have prevented using it on Harmony too.
It can't be called Java unless it passes the TCK. Even so, it only gets a limited trademark license unless you're a paying customer of Oracle. Well fine, without licensing then passing the TCK, you can't call it Java, so what?
Well, since you're foregoing certification, even if you're deriving substantially from the OpenJDK, you're also foregoing the automatic patent grants. And since it's GPLv2, not GPLv3, Oracle or any of the companies who collaborated in the patent licensing scheme, is now free to sue you for billions or trillions.
So no, OpenJDK has a field-of-use restriction in that the only way for a company to build a successful product (or even a failed one) based on it and not get sued into oblivion is to license and pass the TCK to get the license for trademarks and protection for patents.
What Oracle wanted out of the Android/Java-IP lawsuit was an up-front payment in the billions, plus an ongoing cut of Google's android revenue. If they'd won on copyright, which lasts for decades, that could have accrued into a colossal sum of money over time...
Lambdas are in JDK 8 while Android supports JDK 6. This adds support for some of the features of JDK 7. That said, you could backport Lambda to JDK 6...
I'm sure they can be. I'm just at a dead end for the evening and way past the time I should be programming (I was the submitter/author of the OP), thanks though for the encouragement :)
I was just going off the educated guess (without digging through the jdk8 source) that lambdas, like most other syntax features on Java, are just syntactical sugar that does not modify the underlying bytecode since jdk6 and so does not require significant code changes to get it working. Though of course I could be wrong, but I'll deal with that later on in the week.
JDK 8 implements lambda using features in JDK 7 like Invokedynamic. However, they could be implemented as syntactic sugar on top of anonymous inner classes — they just wouldn't be as efficient.
I think lambdas is the one killer feature I would love to see in Android/Java - particularly for a framework such as Androids which is so callback heavy, lambdas would be an immense help.