The New Android Compilers - Meet Jack And Jill
Written by Harry Fairhead   
Friday, 12 December 2014

The new compiler toolchain, Jack and Jill, were included in the recent release of Android SDK 21.1, but only now has Google explained what they are are and what they do.

 

 

The fanciful names give most of the game away. Jack is Java Android Compiler Kit and Jill is Jack Intermediate Library Linker. At the moment both have the status of "experimental". 

The idea is very simple. Jack compiles your Java code directly to a .dex Dalvik Executable. The usual compilation process takes the source code and uses the standard javac compiler to convert it first to Java bytecode and then feeds this through the dex compiler to convert it to Dalvik bytecode.

The new Jack compiler does this job in one go without using Java bytecode. It also applies optimization and the obfuscation that used to be provided by Proguard. This is a much simpler one-step process and Google hopes to take even more advantage of it in the future with features such as incremental compilation. I guess you could say that at last Android has its own compiler. 

Notice that the resulting .dex code can be feed to the traditional Dalvik engine or to the newer ART Android RunTime engine. The ART engine uses Ahead-of-Time compilation, which is what we once used to call "compilation" to convert the .dex to native code at installation time. This can be much faster.  

So what does Jill do? 

The simple answer is that it shields Jack from ever having to see and process any Java bytecode. If you have a library, Jill will convert the .jar library files into the .jack library format which Jack can merge with the rest of the object code. 

The complete process can be seen in the diagram below:

 

jackjill1

 

At the moment you have to enable support for Jack and Jill if you want to use it. This amounts to adding useJack=true to your build.gradle file. There is a lot more detail on the Android Developer's site. 

So why is Google moving to Jack and Jill?

There is the possibility that by streamlining the compiler sequence there is scope for more optimization - like the incremental compile mentioned earlier. 

Another less technical reason might be the need for Google to move away from Dalvik and the Java infrastructure to make the Oracle lawsuit less of a problem. Although there was a ruling that basically said that it was fine for Google to use Java APIs etc, this is still being appealed and this time it doesn't look so good for Google. Not using javac and Dalvik places some distance between Android technology and the Java lawsuit. 

On the downside Jack and Jill currently don't support Java 8 and any upgrades are going to have to be implemented by Google. When Android was new, being compatible with the Java language and infrastructure was a big deal, but now it is almost Java that needs Android. 

 

lollipopicon

Banner


PlanetScale Gets Into Vector Search
02/12/2024

PlanetScale, the cloud MySQL-compatible database with advanced scaling capabilities, is now upgraded with vector storage and search.



Fermyon's Spin WebAssembly Version 3.0 Released
26/11/2024

The open source developer tool for building, distributing, and running serverless WebAssembly applications reaches version 3.0. What's new?


More News

 

espbook

 

Comments




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

 

 

 

 

 

Last Updated ( Friday, 12 December 2014 )