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?
My impression from the post was that they were going back to the old (standard) way of letting the standard javac compile Java to bytecode and then letting dx convert it to Dalvik bytecode, but now with the addition of Java 8 bytecode support in dx. Their stated reason is precisely what you bring up: compatibility with tools that work with the bytecode, like the Scala compiler.
Is this impression incorrect? Are they doing something special with the Java source code instead of processing the byte code? Are they doing their own javac compiler?
This is the exact opposite of what I got from reading this blog post... Jack is what did the bad stuff you are talking about, Jill was (apparently: I hadn't read much about it before today) a mitigation for that badness (by allowing you to "link" in .class files), and they finally decided to throw all that away and go back to actually (correctly, in my book) supporting the old javac->dx flow (which guarantees that if they are going to support Java 8, and this blog posts claims they are intending to do so, that they do it by supporting the bytecode correctly, as now all source code has to go through this path and the Java ecosystem of code transformers will continue to work as expected).
Google has no interest in providing the right support for Java developers it seems.
Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement.
And of course, lack of many of the SE APIs in any case.
The fun of writing portable libraries between Java and Android Java is only getting better.
>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
To quote the article: "We've decided to add support for Java 8 language features directly into the current javac and dx set of tools."
The way I'm reading that could (maybe) work, the regular toolchain (javac -> .class files -> dx -> dex file) would get an upgraded dx tool that could take classes with Java 8 bytecode as input. In that case something like Scala (or any compiler that outputs Java 8 bytecode classes) would be just as well supported.
>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:
Well, you can hardly add those features onto devices that don't have them in their standard library. Even now all the features that require modification of the runtime are restricted to the VMs actually supporting them (e.g. try-with-resources since Android 4.4, most other new Java 8 features since Android 6.0 I think).
(Yes, it would be nice if new Android versions would expand the standard library).
In the end I don't see that as a huge restriction - instead of java.time there's ThreetenABP, instead of streams there's better RxJava, etc. With added bonus that you're not limited to whatever libraries device ships with, but you bring your own always up to date ones.
Also, right now, any new project should pretty much be started in Kotlin which does everything that Java 8 does better and is bytecode compatible with Android VMs.
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?
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.
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.
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).
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?
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.
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.
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.
[+] [-] dkarl|9 years ago|reply
[1] https://www.scala-lang.org/download/#Software_Requirements
[2] http://stackoverflow.com/questions/35958814/how-jack-java-an...
[+] [-] ptx|9 years ago|reply
Is this impression incorrect? Are they doing something special with the Java source code instead of processing the byte code? Are they doing their own javac compiler?
[+] [-] saurik|9 years ago|reply
[+] [-] makeramen|9 years ago|reply
[+] [-] pjmlp|9 years ago|reply
Lack of Java 8 bytecode now, then lack of Java 9 modules tomorrow, and eventually lack of Java 10 value types and improved generics, arrays and JNI replacement.
And of course, lack of many of the SE APIs in any case.
The fun of writing portable libraries between Java and Android Java is only getting better.
[+] [-] agentjj|9 years ago|reply
To quote the article: "We've decided to add support for Java 8 language features directly into the current javac and dx set of tools."
The way I'm reading that could (maybe) work, the regular toolchain (javac -> .class files -> dx -> dex file) would get an upgraded dx tool that could take classes with Java 8 bytecode as input. In that case something like Scala (or any compiler that outputs Java 8 bytecode classes) would be just as well supported.
[+] [-] izacus|9 years ago|reply
[+] [-] bitmapbrother|9 years ago|reply
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/an...
[+] [-] pianoben|9 years ago|reply
...I hope they fix IntelliJ's default suggestions, which try to turn all of your loops into `.stream()` calls!
[+] [-] lstamour|9 years ago|reply
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-...
[+] [-] exabrial|9 years ago|reply
[+] [-] izacus|9 years ago|reply
(Yes, it would be nice if new Android versions would expand the standard library).
In the end I don't see that as a huge restriction - instead of java.time there's ThreetenABP, instead of streams there's better RxJava, etc. With added bonus that you're not limited to whatever libraries device ships with, but you bring your own always up to date ones.
Also, right now, any new project should pretty much be started in Kotlin which does everything that Java 8 does better and is bytecode compatible with Android VMs.
[+] [-] DiabloD3|9 years ago|reply
If it is suggesting it on a correctly configured Android project, I suspect you found a bug.
[+] [-] future1979|9 years ago|reply
[+] [-] izacus|9 years ago|reply
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.
[+] [-] akent|9 years ago|reply
[+] [-] agentjj|9 years ago|reply
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).
[+] [-] izacus|9 years ago|reply
[+] [-] Cyph0n|9 years ago|reply
[+] [-] clay_to_n|9 years ago|reply
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.
[+] [-] Rebelgecko|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] maaaats|9 years ago|reply
[+] [-] izacus|9 years ago|reply
[+] [-] relics443|9 years ago|reply
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|9 years ago|reply
[+] [-] izacus|9 years ago|reply
See https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] gens|9 years ago|reply
[+] [-] js2|9 years ago|reply