Since you have to read a long way through the FAQ to find out, here are the answers to the two most important questions I had:
Q) So what works from Java 7?
A) All the syntatic sugar stuff and also "try with resources." (see below)
1) String Switches
2) Try with resources (a.k.a "using/with", auto close)
3) Multiple exception caught in one catch block
4) Integer (and binary) literals for readability (e.g. 100_000_000 or 20_000 or 0b0111_0000)
5) Type inference on collections (a.k.a. "diamonds")
Q) What doesn't work?
1) java.nio.*
2) threading and multiple processor enhancements (fork/join)
3) File change notifications (watch/notify file api stuff)
4) invokedynamic
Its unfortunate that google haven't worked to bring more modern java language features to Android, although I imagine that the Android group has been kept rather busy with other things. Still, Google io is coming, with what is sure to be a slew of new product and feature announcements, so one can hope ...
Sorry about burying the most important questions. I moved them to the top of the FAQ now :)
I really wish Google would just make amends with the Apache Foundation and work with them on improving OpenJDK. It would be so much better for both (and us developers) if they did.
All the unimplemented stuff falls under more than a weekend project and not sure how nice some of it would play with Android's APIs and Dalvik. The only thing I would really love to see outside of what was able to easily get working is Lambdas.
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 am starting to think Google will leave Java language support at Java 6 level, or eventually offer full native support, instead of the half solution that the NDK currently offers.
Looking forward to this year's Google IO to see if there will be any change at that level.
It's not impossible for Google to work out a licensing deal with Oracle, but I'd just as soon expect them to come up with their own LLVM-based language implementation or announce LLVM support for one they've already developed, given that they added Clang (and thus, LLVM) support to NDKv8 in November 2012.
Sort of. It has issues with ProGuard, but the Scala standard library is a couple of megabytes, so you'll be adding some size to your application, or you'll have to very carefully test and configure.
Additionally, Dalvik didn't have JIT until late in its maturity, so besides the normal slowdown from Java->Scala, expect it to slow down further by the less-efficient VM.
It might be viable on newer devices, but it'll definitely have problems on older ones. Other than that, it does seem very feasible to write and deploy a Scala Android app.
Kotlin might have a better time on Android (though I too would prefer Scala), or at least better support. I haven't tried it yet on Android, but Jetbrains had a small tutorial for it on their blog[1]. I've just been putting it off since it was an immature language, but that may not be quite as true now.
Have you built a substantial application using Scala on Android? Bump uses Scala, and they had to do a lot of messing with build processes, and they ended up using Java for performance in places as well. I can't find the talk right now, but here's the slides: http://www.slideshare.net/michael.galpin/scala-on-android-ex...
Admittedly, my experience on this was running it on now-ancient Android devices before Dalvik had JIT, and ProGuard at the time seemed to always render Scala apps un-runnable, for whatever reason. At least for me at the time, it was questionable. Nowadays, given the amount of work put into it, I'd put some trust in running it in production. But I'd still expect issues to come up now and then, as it's not a natively supported platform.
I think using Kotlin[1] or Xtend[2] might be a better option, because the projects explicitly support Android, while Scala and Clojure support are side projects by the community.
