6 ms·

I like the changes in Java 8, but I'm concerned about Java fragmentation between Oracle/OpenJDK and Android. It seems Android is stuck on Java 1.6 (since Dalvi

I like the changes in Java 8, but I'm concerned about Java fragmentation between Oracle/OpenJDK and Android. It seems Android is stuck on Java 1.6 (since Dalvik is not "true Java" and is more like a VM that happens to implement a language very similar to Java 1.6). There's now a huge gap between 1.6 and 1.8. It's not just syntax like lambda and default methods. It's also the supporting API changes in collections (streams) and others. Dalvik was based on Apache Harmony which is a dead project and will never get the Java 8 API changes implemented. Does anyone know if Google is going to do something about Java 8 and Android?

eloisant 12y ago
There's always been some fragmentation between Dalvik and "real" Java. A lot of libraries don't work out of the box on Android.
spullara 12y ago
There is a good reason that Sun didn't want this to happen and tried to stop it in court — successful against Microsoft, failed against Google. If I remember right, most everyone on here was rooting for Google to win and continue to fragment the language.
- _pmf_ 12y ago
  The question is what Oracle would lose by licensing real Java to Google at reasonable conditions. Mobile non-Android Java is deader than dead.
  - pjmlp 12y ago
    > Mobile non-Android Java is deader than dead. Lots of embedded devices make use of J2ME, e.g. cars, manufacturing, electricity monitoring...
    - thwarted 12y ago
      How many of those will get Java 8 updates?
  - beat 12y ago
    The billionaires at WhatsApp beg to differ. They got very very rich from "mobile non-Android Java".
    - hatred 12y ago
      Isn't their stack based on Erlang or am I missing something ?
      - cgh 12y ago
        You're missing the client side. It runs on J2ME-powered feature phones.
        krzyk 12y ago
        And on Android (and probably iPhones). Which version was first, J2ME or smartphone one?
  - spullara 12y ago
    Oracle was offering licensing for "real Java" at around $1 per device. This was too high for Google that wanted to make it entirely free. Kind of silly, since Android hardware manufacturers pay much more than that to Microsoft in patent licenses.
    - jsight 12y ago
      It's unlikely that the patent licensing situation would have been different with Java ME. It is entirely likely that it would not have been completely open source due to Sun (and ultimately Oracle) restrictions on Java ME.
- pjmlp 12y ago
  I have since repent myself. Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations. Even J2ME is more compatible with its big brother than Android. KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode. And since almost no one has KitKat, one cannot use try-with-resources anyway.
  - bananas 12y ago
    I wrote a lot of J2ME stuff a few years ago and you're spot on. I spent two weeks doing Java 8 bits with NetBeans which was really nice and spent the last two evenings writing my first Android app and what a complete mess it is. Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse". Late edit: perhaps Oracle should make a phone ;)
    - pjmlp 12y ago
      I also did some J2ME stuff back in 2003, most with Sharp and Nokia devices. I read somewhere that some in the Android team are C converts doing their first Java gig. Have you seen how broken are the generated Renderscript bindings? They don't have anything to do with Java conventions and feel completely out of place.
      - bananas 12y ago
        Haven't looked at render script yet. Still scratching head on the layout engine stuff and View infrastructure. It's fugly. I usually write C#+WPF and C++/Qt and HTML/Java EE and all of those are massively nicer to deal with.
        stusmall 12y ago
        If you are two days in and still getting around how Views and layout works I wouldn't call it a mess yet. You are still pretty early into it. Its not messy its just new to you. From my experience once you get past the initial hump of learning their basic APIs and conventions its a very easy to work with platform. Maybe I am biased because I spend a lot of time with it. I also really like the tooling. How is it acting unstable for you?
- icebraining 12y ago
  I supported Google because the ends don't justify means. People should have the right to re-implement APIs, even if we sometimes wished they didn't.
  - squeaky-clean 12y ago
    Well put. Just because it wasn't a good idea doesn't mean it should be illegal.
- jayd16 12y ago
  Forked != out of date. Android code is still Java code. you just compile to Dalvik bytecode instead of jvm bytecode. If you think that's wrong, fine but that lawsuit had nothing to do with bytecode.
mhaymo 12y ago
Android already supports most of Java 7 http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7 http://tools.android.com/tech-docs/new-build-system/user-gui... I'm not aware of any plans to support Java 8 yet, but I haven't been looking.
- cpprototypes 12y ago
  They support Java 7 syntax, however they do not have the API improvements in Java 7. For example, Java 7 introduced a much improved File IO API in the java.nio.file package. It has very useful classes like Files (http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...) Android does not have any of this (http://developer.android.com/reference/packages.html http://developer.android.com/reference/packages.html) because the Apache Harmony project died before it could implement Java 7 API changes. This is a much bigger issue for Java 8. Just supporting only Java 8 syntax changes greatly reduces the benefits of the new lambda and default methods. Much of the power of the changes, especially lambda, require the changes to the collections API.
  - bradleyjg 12y ago
    Guava works on it though, thank goodness!
  - koko775 12y ago
    No, Android does not have any of this because Apache Harmony was killed by the Java 7 API changes. Namely, the documentation was no longer open, and Oracle withheld the TCK, effectively killing Harmony by making it uncertifiable as a Java implementation. Harmony didn't die per se - It was killed by Oracle. Google's rationale for engineering a Java-ish VM with Java APIs was only legal up until Java 6.
- pjmlp 12y ago
  If you target only KitKat and don't mind missing some of the Java 7 new APIs.
higherpurpose 12y ago
Especially since Google hasn't updated its Java language much lately. I think the solution for Google is to deprecate Java and start using Go. That would solve more than one problem for them.
- pjmlp 12y ago
  Back when I was initially impressed by Go before the 1.0 release, I created a ticket for Go on Android, which is still open. I doubt it will ever happen.
  - jaegerpicker 12y ago
    There are a bunch of rumors that Google will announce expanded GoLang support on Android at IO. What that means I'm not sure and I can't find the link for it now. It was a somewhat credible source but not one I'd bet the farm on or anything. I suspect if anything is announced it would be GoLang ndk support but we can dream and hope for more. A python to Davlik compiler would be a very interesting move also.
    - pjmlp 12y ago
      > A python to Davlik compiler would be a very interesting move also. Dalvik is dead. It has been already fully replaced on the latest AOSP code drops. Plus SL4A was left to rotten. As for Go, lets see. My ticket is now two years old.
- jayd16 12y ago
  > Especially since Google hasn't updated its Java language much lately Yes it has. They recently added Java 7 language support.
mncolinlee 12y ago
Dalvik is being slowly replaced by ART (Android RunTime). Also, you can pretty easily hack Java 7 or even Java 8 into Android to use lambdas. Official, default support is coming soon. http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7 http://tools.android.com/tech-docs/new-build-system/user-gui... http://zserge.com/blog/android-lambda.html http://zserge.com/blog/android-lambda.html
- pjmlp 12y ago
  Except those lambdas are not as efficient as the standard compliants VMs, as they make use of invokedynamic to generate better code, even inline calls for small lambdas.
  - Groxx 12y ago
    Which might be fixable with ART as it's an on-device ahead-of-time compiler (I think it optimizes too? can't find references...). I have no idea if it actually does work for this in practice or not, though.
    - pjmlp 12y ago
      True, but it won't help users with KitKat and lower devices. We all know that they won't see any vendor updates.
      - Groxx 12y ago
        Well sure. But people don't update their Java installs either, neither do all businesses. They're likely not going to be able to take advantage of v8 stuff. And can dumbphones on a Java platform (Symbian? Nokia? Others?) run the new Java flashiness? Every platform has problems like this.
  - georgewfraser 12y ago
    Are you sure about that? I've looked at the way invokedynamic generates lambdas, and it's just generating anonymous classes at runtime using ASM. Inlining is from the JIT and applies to anonymous classes as well. I'm pretty sure you can get the exact same results without invokedynamic, you just have a lot more .class files to distribute.
izacus 12y ago
Hmm, what you write makes no sense.... even if Google would use Oracle Java, we'd still be stuck with devices running Java 1.6 JVMs. Having a different implementation doesn't change the limitations imposed by out of date VM running on a device.
- spullara 12y ago
  Why would they run 1.6 JVMs? Why wouldn't they run the latest?
donniezazen 12y ago
Not to mention debacle it creates on your system. Android requires/plays-well with JDK 6 and you probably want to be running the latest version of Java for security purposes. Maintaining multiple JDKs have been nothing but troubling for me.
- izacus 12y ago
  Uhm... Android tools work just fine with the newsest stable JDK 7.
  - donniezazen 12y ago
    I hear not all libraries are supported. developer.android.com and almost all tutorials/courses recommend using JDK 6.

eloisant 12y ago

There's always been some fragmentation between Dalvik and "real" Java. A lot of libraries don't work out of the box on Android.

spullara 12y ago

There is a good reason that Sun didn't want this to happen and tried to stop it in court — successful against Microsoft, failed against Google. If I remember right, most everyone on here was rooting for Google to win and continue to fragment the language.

_pmf_ 12y ago
The question is what Oracle would lose by licensing real Java to Google at reasonable conditions. Mobile non-Android Java is deader than dead.
- pjmlp 12y ago
  > Mobile non-Android Java is deader than dead. Lots of embedded devices make use of J2ME, e.g. cars, manufacturing, electricity monitoring...
  - thwarted 12y ago
    How many of those will get Java 8 updates?
- beat 12y ago
  The billionaires at WhatsApp beg to differ. They got very very rich from "mobile non-Android Java".
  - hatred 12y ago
    Isn't their stack based on Erlang or am I missing something ?
    - cgh 12y ago
      You're missing the client side. It runs on J2ME-powered feature phones.
      - krzyk 12y ago
        And on Android (and probably iPhones). Which version was first, J2ME or smartphone one?
- spullara 12y ago
  Oracle was offering licensing for "real Java" at around $1 per device. This was too high for Google that wanted to make it entirely free. Kind of silly, since Android hardware manufacturers pay much more than that to Microsoft in patent licenses.
  - jsight 12y ago
    It's unlikely that the patent licensing situation would have been different with Java ME. It is entirely likely that it would not have been completely open source due to Sun (and ultimately Oracle) restrictions on Java ME.
pjmlp 12y ago
I have since repent myself. Google did indeed managed to pull a Microsoft and now we have a forked Java implementation getting steady behind the standard Java implementations. Even J2ME is more compatible with its big brother than Android. KitKat has now partial support for Java 7, with libraries still missing some pieces. Dalvik and ART still don't support invokedynamic bytecode. And since almost no one has KitKat, one cannot use try-with-resources anyway.
- bananas 12y ago
  I wrote a lot of J2ME stuff a few years ago and you're spot on. I spent two weeks doing Java 8 bits with NetBeans which was really nice and spent the last two evenings writing my first Android app and what a complete mess it is. Plus the Android tooling is horrible to get working reliably - most problems being solved by "restart eclipse". Late edit: perhaps Oracle should make a phone ;)
  - pjmlp 12y ago
    I also did some J2ME stuff back in 2003, most with Sharp and Nokia devices. I read somewhere that some in the Android team are C converts doing their first Java gig. Have you seen how broken are the generated Renderscript bindings? They don't have anything to do with Java conventions and feel completely out of place.
    - bananas 12y ago
      Haven't looked at render script yet. Still scratching head on the layout engine stuff and View infrastructure. It's fugly. I usually write C#+WPF and C++/Qt and HTML/Java EE and all of those are massively nicer to deal with.
      - stusmall 12y ago
        If you are two days in and still getting around how Views and layout works I wouldn't call it a mess yet. You are still pretty early into it. Its not messy its just new to you. From my experience once you get past the initial hump of learning their basic APIs and conventions its a very easy to work with platform. Maybe I am biased because I spend a lot of time with it. I also really like the tooling. How is it acting unstable for you?
icebraining 12y ago
I supported Google because the ends don't justify means. People should have the right to re-implement APIs, even if we sometimes wished they didn't.
- squeaky-clean 12y ago
  Well put. Just because it wasn't a good idea doesn't mean it should be illegal.
jayd16 12y ago
Forked != out of date. Android code is still Java code. you just compile to Dalvik bytecode instead of jvm bytecode. If you think that's wrong, fine but that lawsuit had nothing to do with bytecode.

mhaymo 12y ago

Android already supports most of Java 7 http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7 http://tools.android.com/tech-docs/new-build-system/user-gui... I'm not aware of any plans to support Java 8 yet, but I haven't been looking.

cpprototypes 12y ago
They support Java 7 syntax, however they do not have the API improvements in Java 7. For example, Java 7 introduced a much improved File IO API in the java.nio.file package. It has very useful classes like Files (http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files...) Android does not have any of this (http://developer.android.com/reference/packages.html http://developer.android.com/reference/packages.html) because the Apache Harmony project died before it could implement Java 7 API changes. This is a much bigger issue for Java 8. Just supporting only Java 8 syntax changes greatly reduces the benefits of the new lambda and default methods. Much of the power of the changes, especially lambda, require the changes to the collections API.
- bradleyjg 12y ago
  Guava works on it though, thank goodness!
- koko775 12y ago
  No, Android does not have any of this because Apache Harmony was killed by the Java 7 API changes. Namely, the documentation was no longer open, and Oracle withheld the TCK, effectively killing Harmony by making it uncertifiable as a Java implementation. Harmony didn't die per se - It was killed by Oracle. Google's rationale for engineering a Java-ish VM with Java APIs was only legal up until Java 6.
pjmlp 12y ago
If you target only KitKat and don't mind missing some of the Java 7 new APIs.

higherpurpose 12y ago

Especially since Google hasn't updated its Java language much lately. I think the solution for Google is to deprecate Java and start using Go. That would solve more than one problem for them.

pjmlp 12y ago
Back when I was initially impressed by Go before the 1.0 release, I created a ticket for Go on Android, which is still open. I doubt it will ever happen.
- jaegerpicker 12y ago
  There are a bunch of rumors that Google will announce expanded GoLang support on Android at IO. What that means I'm not sure and I can't find the link for it now. It was a somewhat credible source but not one I'd bet the farm on or anything. I suspect if anything is announced it would be GoLang ndk support but we can dream and hope for more. A python to Davlik compiler would be a very interesting move also.
  - pjmlp 12y ago
    > A python to Davlik compiler would be a very interesting move also. Dalvik is dead. It has been already fully replaced on the latest AOSP code drops. Plus SL4A was left to rotten. As for Go, lets see. My ticket is now two years old.
jayd16 12y ago
> Especially since Google hasn't updated its Java language much lately Yes it has. They recently added Java 7 language support.

mncolinlee 12y ago

Dalvik is being slowly replaced by ART (Android RunTime). Also, you can pretty easily hack Java 7 or even Java 8 into Android to use lambdas. Official, default support is coming soon. http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Using-sourceCompatibility-1.7 http://tools.android.com/tech-docs/new-build-system/user-gui... http://zserge.com/blog/android-lambda.html http://zserge.com/blog/android-lambda.html

pjmlp 12y ago
Except those lambdas are not as efficient as the standard compliants VMs, as they make use of invokedynamic to generate better code, even inline calls for small lambdas.
- Groxx 12y ago
  Which might be fixable with ART as it's an on-device ahead-of-time compiler (I think it optimizes too? can't find references...). I have no idea if it actually does work for this in practice or not, though.
  - pjmlp 12y ago
    True, but it won't help users with KitKat and lower devices. We all know that they won't see any vendor updates.
    - Groxx 12y ago
      Well sure. But people don't update their Java installs either, neither do all businesses. They're likely not going to be able to take advantage of v8 stuff. And can dumbphones on a Java platform (Symbian? Nokia? Others?) run the new Java flashiness? Every platform has problems like this.
- georgewfraser 12y ago
  Are you sure about that? I've looked at the way invokedynamic generates lambdas, and it's just generating anonymous classes at runtime using ASM. Inlining is from the JIT and applies to anonymous classes as well. I'm pretty sure you can get the exact same results without invokedynamic, you just have a lot more .class files to distribute.

izacus 12y ago

Hmm, what you write makes no sense.... even if Google would use Oracle Java, we'd still be stuck with devices running Java 1.6 JVMs. Having a different implementation doesn't change the limitations imposed by out of date VM running on a device.

spullara 12y ago
Why would they run 1.6 JVMs? Why wouldn't they run the latest?

donniezazen 12y ago

Not to mention debacle it creates on your system. Android requires/plays-well with JDK 6 and you probably want to be running the latest version of Java for security purposes. Maintaining multiple JDKs have been nothing but troubling for me.

izacus 12y ago
Uhm... Android tools work just fine with the newsest stable JDK 7.
- donniezazen 12y ago
  I hear not all libraries are supported. developer.android.com and almost all tutorials/courses recommend using JDK 6.