The Jack and Jill: Should you use in your next Android Application?

Keval Patel

5 min readDec 28, 2016

With the release of Android N preview back in May 2016 Google also officially released a new compilation chain called Jack and Jill. Wait!!! This is not nursery rhymes. This is way more complex than those rhymes. :-)
Jack which stands for Java Android Compiler Kit and Jill which is an acronym for Jack Intermediate Library Linker are intended to replace existing javac + dx toolchains.
Before diving into how jack and Jill works, let’s take a close look at how android compilation work till today’s date. After that, we will see how we can use Jack in your android application project.

Android Compilation process:

Let’s look into how android compilation process works. Here, We are going to take bird eye’s view of the compilation process. I am not going to describe each and every component of the toolchain in detail.
Since, the launch of Android OS, the compilation process works as below:

We have our java code into the .java file. When we start compiling the application source code, it compiles in two steps. First, the source code gets compiled using Java compiler (javac) and the .class file with compiled bytecode is generated. This is the common process to run java application on JVM (Java Virtual Machine). But, Android system does not use JVM to run the applications. It uses Dalvik (or ART in Android L+) which is highly optimized to for the mobile environment. Hence, the compiler has changed, the bytecode will be generated from the source code also need to modify. This is where the second step comes into the picture. In the second step, -dx tool will take .class file generated from Java Compiler as input and it modifies the bytecode into a .dex file. Now, our Dalvik (or ART) can understand and run those .dex files.
You might be thinking what about the third party libraries, which we include in our project? Those third-party libraries come into .jar or .aar format. The .jar file is nothing but the zip of .class files. So, whenever you compile those libraries in your project, -dx tool will convert them into .dex file.

When we use tools that do bytecode manipulation, (like Proguard to remove unused code and obfuscate the source file or Retrolambda to use Java 8 features like lambda expression and method reference in Java 7) it takes .class file as input, modify their bytecode and generate new .class files. Later those modified class files will be converted to .dex file using -dx tool and that will produce the final result.

How Jack is different from legacy javac+dx?

Jack compiler combines above two step (javac +dx) from the compilation toolchain into one single step. It takes .java file as an input and provides .dex files in the output. Pretty cool, huh!!! We don’t need to produce intermediate .class files. So, no more need for the .dx tool.

Wait, what about the third party library? They come into .class file format. As we discussed, Jack Compiler do not take .class files as input. Here, Jill comes to the picture. Jill will process those .class files and convert them into special .jack format. Jack compiler can take .jack files as input and generate the .dex file from that.

What about those tools we get addicted using like Proguard and Retrolambda? Those plugins use .class file and process them. Now with Jack toolchain don’t generate .class file during compilation.
Proguard is baked inside the Jack toolchain. So, we can use those in our application without any worries.
For Retrolambda, we don’t need that anymore. Jack can handle all lambdas perfectly. (And I am very excited about that.)
Of Course, you won’t be able to use other useful tools like Jacoco for now. But honestly, I don’t care about them! :-) Hope, Google will support them in the future.

How to enable Jack toolchain in your applications?

Enable support for the Jack toolchain in your module level build.gradle file.

To enable support for Java 8 features add below lines in your module level build.gradle.

If you want to enable more features like annotation processing visit this.

What are we gaining?

The biggest gain of using Jack compiler over legacy javac+dx is the ability to process Java 8 expressions. Jack supports lambda expressions, method references and typed annotations out of the box. You may argue that tools like Retrolambda also providing the support for those features. But, the overall method counts generated by Jack while compiling lambda expressions and method references in the final bytecode is far less than Retrolambda. This a huge gain as we want to keep method counts less than 64K to prevent multidexing in android.

Method count comparison between Retrolambda and Jack (Source : https://www.youtube.com/watch?v=WALV33rWye4)

Previously, toolchain uses javac. That means android compilation toolchain implementations are controlled by other groups like Oracle, Eclipse, or the OpenJDK project. Now, due to new Jack toolchain, Google has total control over the compilation toolchain, they can add some features specific to the Android compilation in the toolchain itself. (e.g. Proguard is now available in Jack toolchain by default.)

What are the downsides?

Transform APIs are not supported by the Jack compiler. So, third party plugins like Jacoco are currently not supported by Jack toolchain.
Jack is currently slower than javac + dx.
Lint detectors which operate on a Java bytecode level will not work since there isn’t intermediate bytecode (.class files) when you use Jack.
Instant Run in android studio 2.0 and higher does not currently work with Jack and will be disabled while using the new toolchain.

Conclusion:

Jack and Jill toolchain is a very cool move by Google to make android specific compilation toolchain. It will surely make a strong impact on Android development in future. But, right now it is in very early stage and it will take the time to gain popularity.

If you liked the article, click the 💚 below so more people can see it! You can follow me on Medium and Twitter to keep in touch with me.