In a surprise announcement, the Android development team has made it clear that the new Jack compiler and Jill linker are not going anywhere. The move to Java 8 will now be made by developing the existing javac compiler. 

In creating Android, Google did fork the Java eco system, whatever they might claim to the contrary. It made use of an incompatible virtual machine, Dalvik, that runs non-Java byte code called dex. To run Java on Dalvik you first compile the program in the usual way and then use dx to translate Java byte code into dex. Since Android 4.4 (Kitkat) the Dalvik VM has been replaced by ART, the Android RunTime, but this still runs dex code. 

This two-stage Java to Java byte code and then byte code to dex process had its problems and in 2012 the Jack project or "experiment" if you like, was announced. This consisted of a new compiler that would take Java code and convert it directly to dex. Along the way the idea was that the latest Java innovations in Java 8 could be included and Jack was a way to keep Android's Java up-to-date with the rest of the Java world. Not having Java 8 features isn't a huge problem, but it does mean that Android programmers can't make use of lambdas, say, for event handling. 

The advantage of using Jack are: 

• Completely open source
  
  
• Speeds compilation time
  Jack has specific supports to reduce compilation time: pre-dexing, incremental compilation and a Jack compilation server.
  
  
• Handles shrinking, obfuscation, repackaging and multidex
  Using a separate package such as ProGuard is no longer necessary. 

The purpose of Jill, apart from being the other half of a good joke, is to convert existing jar libraries into the new jack library format. 

There were some problems with this approach, however. One practical problem was that it wasn't well integrated with Android Studio, so even now many programmers don't make use of the Jack tool chain. It also didn't support the instant run feature of the latest Android Studio that made it possible to run apps by applying incremental changes rather than downloading the entire APK each time. In addition to all this, it turns out that sometimes it is useful to have the Java byte code as an intermediate because many tools, annotation processors, bytecode analyzers and rewriters, work with it. If Android moves to Jack then all of the tools that work with byte code before it is compiled to dex would no longer be available. 

The blog post claims that this is the reason that the Jack tool chain has been deprecated. 

So how are we going to get Java 8 in to Android?

"We've decided to add support for Java 8 language features directly into the current javac and dx set of tools, and deprecate the Jack toolchain. With this new direction, existing tools and plugins dependent on the Java class file format should continue to work. Moving forward, Java 8 language features will be natively supported by the Android build system. We're aiming to launch this as part of Android Studio in the coming weeks, and we wanted to share this decision early with you. "

Oh good, another major upheaval in the Android Studio landscape. It will be nice to have lambdas but it it really worth it?

Reading between the lines what has to happen is that the dx compiler has to be extended to map the new Java features from the Java 8 byte code to dex. Given the degree of backward compatibility that Java maintains, the big problem is likely to be the restricted byte code set that dx can convert to dex. However there are changes to the byte code in going from Java 7 to 8.

It all sounds very reasonable, except of course the fact that Java 9 is on the horizon and a lot of time has been wasted with the Jack and Jill experiment.

There is, of course the possibility that the shutting down of the Jack toolchain has something to do with the legal problems that Google is having with Oracle, but on the surface it seems that moving back to a dependence on javac is making things worse not better.

One worrying aspect is that the reason given now for dropping Jack and Jill was perfectly clear at the start of the project. It makes you think that perhaps the whole Android enterprise isn't being run by an all-knowing genius. 

So much time wasted and still no lambdas.

• Mike James is author of  of Android Programming: Starting With An App (I/O Press) which is a beginner's guide to using Android Studio. He is currently updating this for Android Studio 2.3, which was released earlier this month.
  Android Programming: Starting With An App, Second Edition (I/O Press) ISBN: 978-1871962512 

More Information

Future of Java 8 Language Feature Support on Android

Related Articles

The New Android Compilers - Meet Jack And Jill 

Android Studio 2.3 - In Need Of Direction

Android Studio 2.2 Preview Big Changes! 

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info

<ASIN:187196251X>