Future of Java 8 Language Feature Support on Android (opens in new tab)

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).

Kotlin is committed to Android support though, and the community is coming to rally behind it much more than Scala.

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.

IMO having Android VM fully compatible with Java 8/9/10 is a non-realistic dream considering what Google is doing now :/

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-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-...

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

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.

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.

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.

>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).

So is OpenJDK and DEX tool used right now.

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.

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

I don't really care, now that I'm invested in Kotlin.

At this point I think any serious shop should be transitioning to Kotlin (just like iOS shops are transitioning to Swift).

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.

See https://www.reddit.com/r/androiddev/comments/5zf1xo/future_o...

Android has long supported C/C++ via JNI and the NDK.