Really bad news for strong Java shops and developers. This move away from Java byte code probably means very little hope for Java 8 compatibility in Android any time soon. For myself, I wrote Java server code for a decade before writing Android apps and the companies I work at often have an order of magnitude more Java server programmers than Android programmers, if they have any Android devs. So more compatibility and feature parity with Java proper would have been great.
Owning more of the toolchain (front and backends) will offer more control and, thus, integration with a more modern development environment. Much like how Apple released Swift this year to replace Objective C in the long run, I imagine Google is positioning itself for a similar evolution with, say, Dart to bridge native and Web app development. If you assume Chrome and Android will eventually be the same thing, certain moves by Google over the last year start to make more sense.
Which is used by the Hotspot JVM's Java 8 lambdas.
It's trivial to translate invokedynamic into Java 6 or Dalvik bytecode, and ART should be smart enough to recognize those translations and generate optimal native binary translations.
> Which is used by the Hotspot JVM's Java 8 lambdas
Not really, because it is part of the Java 8 .class files. So all certified JVMs need to make use of this information.
> It's trivial to translate invokedynamic into Java 6 or Dalvik bytecode, and ART should be smart enough to recognize those translations and generate optimal native binary translations.
Given how Android updates work and the state of Java 7 support across Android versions, I guess many of us will keep on using Java 6/C++ combo.
> Not really, because it is part of the Java 8 .class files.
Dalvik VM and ART handle Dalvik bytecode generated from Java the language, which is separate from the Java virtual machine. Using the same mechanisms as the Java Virtual Machine (and its reference HotSpot implementation) is not technically required to handle features in the Java language, as GCJ, GWT, j2obj, Dalvik, and now ART have shown.
> Given how Android updates work...
Because it is trivial to transform invokedynamic into Dalvik bytecode, my suggested design will work on all existing devices. Indeed, it's possible to use lambdas on Android today (without invokedynamic) with Kotlin, Scala, and Retrolambda, for example. It's possible to further optimize handling of lambdas on future releases.
Invokedynamic is not a significant barrier to implementing lambda support on Android. Handling the class library update is, and Jayce and related tooling seems to provide a way to solve that problem. It might even help provide full support for Java 7 to older devices by putting AutoClosable implementations of classes into the APK when necessary.
> Dalvik VM and ART handle Dalvik bytecode generated from Java the language....
Version 6, with partial support for Java 7 added in Android 4.4 tooling.
> Indeed, it's possible to use lambdas on Android today with Kotlin, Scala, and Retrolambda, for example. It's possible to further optimize handling of lambdas on future releases.
All workarounds for Google's lack of support in the official tooling.
I don't follow. What does this have to do with reducing the possibility of Java 8 compatibility?
One advantage the Jayce development seems to provide is the possibility of optimizing Dalvik bytecode output based on data that is hard to recover from Java bytecode but present in the Java source. Secondarily, there may be build time improvements, but build times aren't C++ bad.
But my best guess at why they did this is to support Java 8 on older devices. Without Proguard in the build system, they would have to include the entire Java 8 class library subset they plan to support in every build, resulting in massive distributables. By building Proguard into the base build system, they can include just the part of Java 8 that is necessary for the app. Jayce likely has some features that make the Proguard tasks easier.
Interesting enough, Google chose to build upon the Eclipse java compiler instead of Sun/Oracle's javac. I'm guessing this is due to javac being GPL and the Android SDK being Apache License 2.0.
This is strangely reminiscent of Apple's strong backing of LLVM.
More competition and corporate funding in the compiler scene is always a good thing.
Perhaps I don't pay attention to these things enough (or haven't seriously worked in Java in a while) but to me it was interesting simply to find out that Eclipse has its own Java compiler instead of using javac.
I found out about it earlier this year when trying to set up Android Studio on the computers at my former high school. I couldn't figure out why I kept getting an error about the JDK being missing until I realized Eclipse had its own compiler and that's how students had been able to compile their Java code for the past four years.
Contrary to the author's claim, ART is not really based on the LLVM toolchain.
It has an LLVM based backend implemented, but it is not the production one and is not used on any device.
I don't remember offhand if they have future plans for it, but at the time, it turned out to not be the best engineering option, and hasn't been touched in a while. The main compilers used are the quick one and the optimizing one.
You can see this yourself, since ART uses AOSP as it's master.
20 comments
[ 4.1 ms ] story [ 53.0 ms ] threadIt's trivial to translate invokedynamic into Java 6 or Dalvik bytecode, and ART should be smart enough to recognize those translations and generate optimal native binary translations.
Not really, because it is part of the Java 8 .class files. So all certified JVMs need to make use of this information.
> It's trivial to translate invokedynamic into Java 6 or Dalvik bytecode, and ART should be smart enough to recognize those translations and generate optimal native binary translations.
Given how Android updates work and the state of Java 7 support across Android versions, I guess many of us will keep on using Java 6/C++ combo.
Dalvik VM and ART handle Dalvik bytecode generated from Java the language, which is separate from the Java virtual machine. Using the same mechanisms as the Java Virtual Machine (and its reference HotSpot implementation) is not technically required to handle features in the Java language, as GCJ, GWT, j2obj, Dalvik, and now ART have shown.
> Given how Android updates work...
Because it is trivial to transform invokedynamic into Dalvik bytecode, my suggested design will work on all existing devices. Indeed, it's possible to use lambdas on Android today (without invokedynamic) with Kotlin, Scala, and Retrolambda, for example. It's possible to further optimize handling of lambdas on future releases.
Invokedynamic is not a significant barrier to implementing lambda support on Android. Handling the class library update is, and Jayce and related tooling seems to provide a way to solve that problem. It might even help provide full support for Java 7 to older devices by putting AutoClosable implementations of classes into the APK when necessary.
Version 6, with partial support for Java 7 added in Android 4.4 tooling.
> Indeed, it's possible to use lambdas on Android today with Kotlin, Scala, and Retrolambda, for example. It's possible to further optimize handling of lambdas on future releases.
All workarounds for Google's lack of support in the official tooling.
One advantage the Jayce development seems to provide is the possibility of optimizing Dalvik bytecode output based on data that is hard to recover from Java bytecode but present in the Java source. Secondarily, there may be build time improvements, but build times aren't C++ bad.
But my best guess at why they did this is to support Java 8 on older devices. Without Proguard in the build system, they would have to include the entire Java 8 class library subset they plan to support in every build, resulting in massive distributables. By building Proguard into the base build system, they can include just the part of Java 8 that is necessary for the app. Jayce likely has some features that make the Proguard tasks easier.
I'm speculating far beyond the OP here.
Nothing, assuming Google cares to implement invokedynamic support.
This is strangely reminiscent of Apple's strong backing of LLVM.
More competition and corporate funding in the compiler scene is always a good thing.
http://eclipse.org/jdt/core/
See also:
http://stackoverflow.com/questions/3061654/what-is-the-diffe...
http://en.wikipedia.org/wiki/Jack_and_Jill_%28nursery_rhyme%...
It has an LLVM based backend implemented, but it is not the production one and is not used on any device.
I don't remember offhand if they have future plans for it, but at the time, it turned out to not be the best engineering option, and hasn't been touched in a while. The main compilers used are the quick one and the optimizing one.
You can see this yourself, since ART uses AOSP as it's master.