10 ms·

Future of Java 8 Language Feature Support on Android

182 points by BrianHV 10y ago

relics443 10y ago
Well that was unexpected. I'm assuming they'll translate bytecode for older API versions? Or will Java 8 only be available for newer API versions?
- lern_too_spel 10y ago
  Are you expecting anybody from the Android team to explain themselves? They've been answering every question about Java 8 with "no comment" for years. They didn't even discuss Jack/Jill's relation to Java 8 support when the tooling was announced, and external developers had to figure out Android's plans on their own from what they could decipher from the architecture.
  - bitmapbrother 10y ago
    Well, when you have an ongoing lawsuit with Oracle you have to careful of what you say in public.
    - pjmlp 10y ago
      They are the ones to blame for it. Apparently every other commercial JVM vendor doesn't have any issue to comply with licenses, while offering their own changes to Java stack. IBM, MicroEJ, Atego, just to cite three examples out of many.
      - AnimalMuppet 10y ago
        Um, do you realize that those licenses prohibit using it on a phone, because Sun/Oracle wanted to protect JavaME? So what you're asking for is for Google to not do Android, and then they wouldn't have the problems that they're having doing Android. That's... not a useful suggestion.
        pjmlp 10y ago
        Google could use them on the phone, they just needed to PAY Sun just like everyone else, but of course they wanted to have the cake for free.
        AnimalMuppet 10y ago
        Given that APIs can't be copyrighted, why shouldn't they have that particular cake for free? (Actually, the current court ruling is that APIs can be copyrighted, but re-implementing them is fair use. My personal IANAL opinion is that that won't stand - it will either turn into "APIs can't be copyrighted" or else into "APIs can be copyrighted, and the copyrights are not worthless - you can't copy it and have it be fair use". We shall see. Nevertheless, at the time Google copied the API, the assumption in the whole industry was that an API could not be copyrighted. Your statement that Google "wanting their cake for free" carries a tone of moral criticism that is unwarranted by the circumstances.)
      - ufmace 10y ago
        Perhaps, but I will say that none of them are nearly as juicy of a lawsuit target as Android, which controls like 70%-ish of the multi-billion device smartphone market right now.
        pjmlp 10y ago
        James Gosling stated multiple times that the only reason Sun didn't sue Google and Jonathan made that public announcement was the state of Sun's bank account. Just search for "Google slimmed Sun".
  - relics443 10y ago
    I've moved on to Kotlin. Much more enjoyable for Android development IMO.
  - izacus 10y ago
    Huh, Android team has been explaning themselves around Java 8 issues a lot (look at I/O talks, linked redding thread in another comment here, etc.)
- izacus 10y ago
  Yeah, it does a similar thing like RetroLambda - things like lambdas are polyfilled and replaced on bytecode level. Some features require newer VMs and I'm afraid standard library won't be expanded with new APIs. See https://www.reddit.com/r/androiddev/comments/5zf1xo/future_of_java_8_language_feature_support_on/dey3jzj/ https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...
deleted 10y ago
[deleted]
Cyph0n 10y ago
Sounds like good news to me, but I'm not sure why this is not getting more attention. Isn't Java 8 support a huge deal for Android, or am I missing something?
- Rebelgecko 10y ago
  They already had something called Jack that let you use java>6 features. It just didn't integrate as well with some parts of the android ecosystem
- deleted 10y ago
  [deleted]
- clay_to_n 10y ago
  It would be awesome. There are some polyfilling libraries, like Retrolambda for lambdas, and ones to get streams etc already, without actually using Java 8. Jack broke a lot of things on Android (like some annotation libraries, which the article mentions), so I think the wider Android community will be happy there's a clear path forward to Java 8.
  - canistr 10y ago
    Enabling Jack also prevented the ability for devs to use Instant Run. It's not a dealbreaker, but combined with all the other broken libraries it definitely added to the frustration with needing/wanting to upgrade to Java 8. I never found it worth upgrading and almost always ignored sample code that showed Jack/Java8 in the gradle files because they didn't seem to be based on real-world usage.
- maaaats 10y ago
  I don't really care, now that I'm invested in Kotlin.
  - ptx 10y ago
    It still seems like good news. If they had decided to focus their efforts on Jack (compiling Java source code directly to Dalvik bytecode) the parts of the toolchain that work with Java bytecode (such as the output of the Kotlin compiler) would have been de-prioritized and might not have been as well supported.
pianoben 10y ago
This looks to be "language features" only - so, lambdas, but no Java 8 APIs. Optionals, streams, etc are not included. ...I hope they fix IntelliJ's default suggestions, which try to turn all of your loops into `.stream()` calls!
- DiabloD3 10y ago
  You can turn that on and off in the settings in IntelliJ already, and it only enables that suggestion if you're using a Java 8 JDK. If it is suggesting it on a correctly configured Android project, I suspect you found a bug.
- lstamour 10y ago
  Just turn them off or use Android Studio, which I believe still has sane defaults. Help file on this: https://www.jetbrains.com/help/idea/2016.3/disabling-and-enabling-inspections.html https://www.jetbrains.com/help/idea/2016.3/disabling-and-ena... Also, if looking for APIs, and willing to risk having to tweak code later, there are a few "polyfills". For example: https://www.google.ca/amp/s/barta.me/enable-java-8-features-android/amp/ https://www.google.ca/amp/s/barta.me/enable-java-8-features-...
- exabrial 10y ago
  I feel like Google really got bit by "not invented here" syndrome on the original Android vm :/ using normal JVM bytecodes might have been a good idea
  - hota_mazi 10y ago
    It would have been a disaster. The JVM of 2007 would have run crazy slow on the devices from back then. Dalvik is the main reason why Android became so popular.
    - bjbX 10y ago
      Every feature phone on the planet used to run Java ME without any problem. Dalvik may have had some optimisations, but to claim Java would have run "crazy slow" is unlikely to be the reason Google chose the implement their own VM.
dkarl 10y ago
The possibility of running Scala >=2.12 (or any other language that is committed to Java 8[1]) on Android seems even more remote now. Jack+Jill at least promised a way of running Java 8 bytecode on Android[2]. What now? Is Java source code going to be the only common currency between the Java 8 and Android ecosystems? [1] https://www.scala-lang.org/download/#Software_Requirements https://www.scala-lang.org/download/#Software_Requirements [2] http://stackoverflow.com/questions/35958814/how-jack-java-android-compiler-kit-will-affect-scala-developers http://stackoverflow.com/questions/35958814/how-jack-java-an...
- makeramen 10y ago
  Kotlin is committed to Android support though, and the community is coming to rally behind it much more than Scala.
  - glibgil 10y ago
    > Is Java source code going to be the only common currency between the Java 8 and Android ecosystems?
  - bad_user 10y ago
    Kotlin is just a Java++, akin to what CoffeeScript is to JS, a Java with a different syntax. Scala is not just a Java with a different syntax. Because of how traits work and because of how they were encoded in Java's class format, in older Scala versions even adding a method with a default implementation breaks binary compatibility, which is why the history of Scala has been so fraught with compatibility breakage. Scala 2.12 takes advantage of Java 8's new default methods in interfaces, among others, for encoding Scala's features. We finally have a Scala version that isn't so fragile. And because of the limited resources of the core team, they can't maintain different backends. Java 8 was released in 2014. I cheered for Google when they won Oracle's lawsuit, but when you're forking the ecosystem, you have a responsibility to keep on your promise of keeping up to date and compatible with the upstream. They just pulled a Microsoft and are getting away with it. Fuck Google for fracturing the Java ecosystem. There, I said it.
akent 10y ago
When they say "into the current javac and dx set of tools" what are they meaning there? How will they do that exactly? I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source.
- izacus 10y ago
  So is OpenJDK and DEX tool used right now.
- agentjj 10y ago
  >How will they do that exactly? Presumably they could have the dx tool in the current toolchain support Java 8 bytecode .class files as input (just as the Jill linker in Jack toolchain allows). >I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source. In the current toolchain you do something like the following: java sources -> javac -> .class files -> dx tool -> dex file -> ... (We already have an open javac with OpenJDK by the way, and dx is part of AOSP, so "entirely open source" was essentially solved). Part of the idea behind Jack was that by creating a new compiler toolchain specifically for Android you could have a faster build by jettisoning the unnecessary .class intermediates and going straight to dex from the sources (or rather, as it turns out, a pre-dex that goes into a new intermediate .jack file with other metadata).
bitmapbrother 10y ago
From the Androiddev reddit https://www.reddit.com/r/androiddev/comments/5zf1xo/future_of_java_8_language_feature_support_on/dey3jzj/ https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o... >I'm guessing the same API restrictions will apply as before? So lambda expressions, method references and type annotations will be available for every API level (so no more retrolambda, or maybe still for try-with-resource?), but other Java 8 features like default and static interface methods and streams are still only for 24 and up? >>Yes, this is correct -- we are currently matching Jack's feature set. That means that we support lambdas, method references, type annotations, and repeated annotations for every API level; default and static interface methods are only supported for 24 and up. We are still not supporting try-with-resources below API 19. Java 8 APIs still depend on the API level since those are included with the OS (sadly, this means no java.time). For anyone interested, the source code for the Java 8 compatibility tool, which we call Desugar, is here: https://github.com/bazelbuild/bazel/tree/master/src/tools/android/java/com/google/devtools/build/android/desugar https://github.com/bazelbuild/bazel/tree/master/src/tools/an...
future1979 10y ago
Tldr for newbie? What is jack all about? I thought android had moved away from dalvik to art in lollipop. In nougot, I thought android was going to use openjdk in some parts. Can anyone knowledgeable shed light?
- izacus 10y ago
  ART and Dalvik are VMs that run on your phone. They're a different implementation of a JVM you know from desktop systems and run a special (non-desktop Java compatible) DEX bytecode format. This is about the toolchain. The standard Android toolchain uses standard OpenJDK/Oracle JDK Java compiler to compile your app code into standard java class files and then uses dex tool to translate that bytecode into Dalvik/ART DEX bytecode. Jack toolchain was all about replacing this javac -> dex step with a single fast compiler which would also support more Java 8 features and translate them into DEX format while taking into account feature limitations of ART/Dalvik runtime. The downside was that it didn't support bytecode manipulation tools (tools that work on Java class files before they're translated into dex format) and annotation code generators. Since a lot of good Android libraries rely on annotation generation that was a pretty huge deal breaker. This news is about Google abandoning the Jack project and retrofitting the improvements and partial Java 8 feature support into current toolchain.
gens 10y ago
How about support for C ?
- js2 10y ago
  Android has long supported C/C++ via JNI and the NDK.

182 points by BrianHV 10y ago

Well that was unexpected. I'm assuming they'll translate bytecode for older API versions? Or will Java 8 only be available for newer API versions?

lern_too_spel 10y ago
Are you expecting anybody from the Android team to explain themselves? They've been answering every question about Java 8 with "no comment" for years. They didn't even discuss Jack/Jill's relation to Java 8 support when the tooling was announced, and external developers had to figure out Android's plans on their own from what they could decipher from the architecture.
- bitmapbrother 10y ago
  Well, when you have an ongoing lawsuit with Oracle you have to careful of what you say in public.
  - pjmlp 10y ago
    They are the ones to blame for it. Apparently every other commercial JVM vendor doesn't have any issue to comply with licenses, while offering their own changes to Java stack. IBM, MicroEJ, Atego, just to cite three examples out of many.
    - AnimalMuppet 10y ago
      Um, do you realize that those licenses prohibit using it on a phone, because Sun/Oracle wanted to protect JavaME? So what you're asking for is for Google to not do Android, and then they wouldn't have the problems that they're having doing Android. That's... not a useful suggestion.
      - pjmlp 10y ago
        Google could use them on the phone, they just needed to PAY Sun just like everyone else, but of course they wanted to have the cake for free.
        AnimalMuppet 10y ago
        Given that APIs can't be copyrighted, why shouldn't they have that particular cake for free? (Actually, the current court ruling is that APIs can be copyrighted, but re-implementing them is fair use. My personal IANAL opinion is that that won't stand - it will either turn into "APIs can't be copyrighted" or else into "APIs can be copyrighted, and the copyrights are not worthless - you can't copy it and have it be fair use". We shall see. Nevertheless, at the time Google copied the API, the assumption in the whole industry was that an API could not be copyrighted. Your statement that Google "wanting their cake for free" carries a tone of moral criticism that is unwarranted by the circumstances.)
    - ufmace 10y ago
      Perhaps, but I will say that none of them are nearly as juicy of a lawsuit target as Android, which controls like 70%-ish of the multi-billion device smartphone market right now.
      - pjmlp 10y ago
        James Gosling stated multiple times that the only reason Sun didn't sue Google and Jonathan made that public announcement was the state of Sun's bank account. Just search for "Google slimmed Sun".
- relics443 10y ago
  I've moved on to Kotlin. Much more enjoyable for Android development IMO.
- izacus 10y ago
  Huh, Android team has been explaning themselves around Java 8 issues a lot (look at I/O talks, linked redding thread in another comment here, etc.)
izacus 10y ago
Yeah, it does a similar thing like RetroLambda - things like lambdas are polyfilled and replaced on bytecode level. Some features require newer VMs and I'm afraid standard library won't be expanded with new APIs. See https://www.reddit.com/r/androiddev/comments/5zf1xo/future_of_java_8_language_feature_support_on/dey3jzj/ https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...

deleted 10y ago

[deleted]

Cyph0n 10y ago

Sounds like good news to me, but I'm not sure why this is not getting more attention. Isn't Java 8 support a huge deal for Android, or am I missing something?

Rebelgecko 10y ago
They already had something called Jack that let you use java>6 features. It just didn't integrate as well with some parts of the android ecosystem
deleted 10y ago
[deleted]
clay_to_n 10y ago
It would be awesome. There are some polyfilling libraries, like Retrolambda for lambdas, and ones to get streams etc already, without actually using Java 8. Jack broke a lot of things on Android (like some annotation libraries, which the article mentions), so I think the wider Android community will be happy there's a clear path forward to Java 8.
- canistr 10y ago
  Enabling Jack also prevented the ability for devs to use Instant Run. It's not a dealbreaker, but combined with all the other broken libraries it definitely added to the frustration with needing/wanting to upgrade to Java 8. I never found it worth upgrading and almost always ignored sample code that showed Jack/Java8 in the gradle files because they didn't seem to be based on real-world usage.
maaaats 10y ago
I don't really care, now that I'm invested in Kotlin.
- ptx 10y ago
  It still seems like good news. If they had decided to focus their efforts on Jack (compiling Java source code directly to Dalvik bytecode) the parts of the toolchain that work with Java bytecode (such as the output of the Kotlin compiler) would have been de-prioritized and might not have been as well supported.

pianoben 10y ago

This looks to be "language features" only - so, lambdas, but no Java 8 APIs. Optionals, streams, etc are not included. ...I hope they fix IntelliJ's default suggestions, which try to turn all of your loops into `.stream()` calls!

DiabloD3 10y ago
You can turn that on and off in the settings in IntelliJ already, and it only enables that suggestion if you're using a Java 8 JDK. If it is suggesting it on a correctly configured Android project, I suspect you found a bug.
lstamour 10y ago
Just turn them off or use Android Studio, which I believe still has sane defaults. Help file on this: https://www.jetbrains.com/help/idea/2016.3/disabling-and-enabling-inspections.html https://www.jetbrains.com/help/idea/2016.3/disabling-and-ena... Also, if looking for APIs, and willing to risk having to tweak code later, there are a few "polyfills". For example: https://www.google.ca/amp/s/barta.me/enable-java-8-features-android/amp/ https://www.google.ca/amp/s/barta.me/enable-java-8-features-...
exabrial 10y ago
I feel like Google really got bit by "not invented here" syndrome on the original Android vm :/ using normal JVM bytecodes might have been a good idea
- hota_mazi 10y ago
  It would have been a disaster. The JVM of 2007 would have run crazy slow on the devices from back then. Dalvik is the main reason why Android became so popular.
  - bjbX 10y ago
    Every feature phone on the planet used to run Java ME without any problem. Dalvik may have had some optimisations, but to claim Java would have run "crazy slow" is unlikely to be the reason Google chose the implement their own VM.

dkarl 10y ago

The possibility of running Scala >=2.12 (or any other language that is committed to Java 8[1]) on Android seems even more remote now. Jack+Jill at least promised a way of running Java 8 bytecode on Android[2]. What now? Is Java source code going to be the only common currency between the Java 8 and Android ecosystems? [1] https://www.scala-lang.org/download/#Software_Requirements https://www.scala-lang.org/download/#Software_Requirements [2] http://stackoverflow.com/questions/35958814/how-jack-java-android-compiler-kit-will-affect-scala-developers http://stackoverflow.com/questions/35958814/how-jack-java-an...

makeramen 10y ago
Kotlin is committed to Android support though, and the community is coming to rally behind it much more than Scala.
- glibgil 10y ago
  > Is Java source code going to be the only common currency between the Java 8 and Android ecosystems?
- bad_user 10y ago
  Kotlin is just a Java++, akin to what CoffeeScript is to JS, a Java with a different syntax. Scala is not just a Java with a different syntax. Because of how traits work and because of how they were encoded in Java's class format, in older Scala versions even adding a method with a default implementation breaks binary compatibility, which is why the history of Scala has been so fraught with compatibility breakage. Scala 2.12 takes advantage of Java 8's new default methods in interfaces, among others, for encoding Scala's features. We finally have a Scala version that isn't so fragile. And because of the limited resources of the core team, they can't maintain different backends. Java 8 was released in 2014. I cheered for Google when they won Oracle's lawsuit, but when you're forking the ecosystem, you have a responsibility to keep on your promise of keeping up to date and compatible with the upstream. They just pulled a Microsoft and are getting away with it. Fuck Google for fracturing the Java ecosystem. There, I said it.

akent 10y ago

When they say "into the current javac and dx set of tools" what are they meaning there? How will they do that exactly? I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source.

izacus 10y ago
So is OpenJDK and DEX tool used right now.
agentjj 10y ago
>How will they do that exactly? Presumably they could have the dx tool in the current toolchain support Java 8 bytecode .class files as input (just as the Jill linker in Jack toolchain allows). >I thought the whole rationale for Jack was it was a clean break from Sun / Oracle Java and entirely open source. In the current toolchain you do something like the following: java sources -> javac -> .class files -> dx tool -> dex file -> ... (We already have an open javac with OpenJDK by the way, and dx is part of AOSP, so "entirely open source" was essentially solved). Part of the idea behind Jack was that by creating a new compiler toolchain specifically for Android you could have a faster build by jettisoning the unnecessary .class intermediates and going straight to dex from the sources (or rather, as it turns out, a pre-dex that goes into a new intermediate .jack file with other metadata).

bitmapbrother 10y ago

From the Androiddev reddit https://www.reddit.com/r/androiddev/comments/5zf1xo/future_of_java_8_language_feature_support_on/dey3jzj/ https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o... >I'm guessing the same API restrictions will apply as before? So lambda expressions, method references and type annotations will be available for every API level (so no more retrolambda, or maybe still for try-with-resource?), but other Java 8 features like default and static interface methods and streams are still only for 24 and up? >>Yes, this is correct -- we are currently matching Jack's feature set. That means that we support lambdas, method references, type annotations, and repeated annotations for every API level; default and static interface methods are only supported for 24 and up. We are still not supporting try-with-resources below API 19. Java 8 APIs still depend on the API level since those are included with the OS (sadly, this means no java.time). For anyone interested, the source code for the Java 8 compatibility tool, which we call Desugar, is here: https://github.com/bazelbuild/bazel/tree/master/src/tools/android/java/com/google/devtools/build/android/desugar https://github.com/bazelbuild/bazel/tree/master/src/tools/an...

future1979 10y ago

Tldr for newbie? What is jack all about? I thought android had moved away from dalvik to art in lollipop. In nougot, I thought android was going to use openjdk in some parts. Can anyone knowledgeable shed light?

izacus 10y ago
ART and Dalvik are VMs that run on your phone. They're a different implementation of a JVM you know from desktop systems and run a special (non-desktop Java compatible) DEX bytecode format. This is about the toolchain. The standard Android toolchain uses standard OpenJDK/Oracle JDK Java compiler to compile your app code into standard java class files and then uses dex tool to translate that bytecode into Dalvik/ART DEX bytecode. Jack toolchain was all about replacing this javac -> dex step with a single fast compiler which would also support more Java 8 features and translate them into DEX format while taking into account feature limitations of ART/Dalvik runtime. The downside was that it didn't support bytecode manipulation tools (tools that work on Java class files before they're translated into dex format) and annotation code generators. Since a lot of good Android libraries rely on annotation generation that was a pretty huge deal breaker. This news is about Google abandoning the Jack project and retrofitting the improvements and partial Java 8 feature support into current toolchain.

gens 10y ago

How about support for C ?

js2 10y ago
Android has long supported C/C++ via JNI and the NDK.