News

Android Turns Its Back on Jack Compiler Toolchain

Coinciding with the coming of Java 8 in 2014, Google adopted the Jack compiler toolchain to simplify all the moving parts required to build an Android mobile app while using the new language features -- an experiment that ended yesterday.

"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," product manager James Lau said in a blog post yesterday.

When announced in December 2014, Jack (Java Android Compiler Kit) was described by Google's Android team as "designed to improve build times and simplify development by reducing dependencies on other tools." Along with Jill (Jack Intermediate Library Linker), it was an experiment to smooth the process of compiling source code into .dex (Dalvik Executable) files containing Dalvik byte code that are zipped into .apk (Android Package Kit) for distribution and installation.

With the new Java 8 features being incorporated into the Android development system, Jack was targeted to replace the existing javac Java compiler included in the Java Development Kit (JDK), along with the dx tool that converts Java class files into .dex files.

The Jack and Jill Build Process
[Click on image for larger view.] The Jack and Jill Build Process (source: Google)

"When the new tool chain is enabled, Jill will translate any libraries you are referencing to a new Jack library file (.jack)," Google said at the time. "This prepares them to be quickly merged with other .jack files. The Android Gradle plug-in and Jack collect any .jack library files, along with your source code, and compiles them into a set of dex files. During the process, Jack also handles any requested code minification. The output is then assembled into an APK file as normal."

The experiment seemed to be working, as Jack support for Android N (subsequently called Nougat) was announced in Android Studio 2.1 (the IDE just moved to version 2.3), bringing Java 8 features into the fold, with support for lambdas getting a lot of attention.

As we reported at the time, a Google exec said of the new OS preview: "With Android's Jack compiler, you can now use many popular Java 8 language features, including lambdas and more, on Android versions as far back as Gingerbread. The new features help reduce boilerplate code. For example, lambdas can replace anonymous inner classes when providing event listeners. Some Java 8 language features -- like default and static methods, streams, and functional interfaces -- are also now available on N and above. With Jack, we're looking forward to tracking the Java language more closely while maintaining backward compatibility."

However, for unspecified reasons, the experiment to rein in all those disparate moving parts while leveraging new Java 8 features didn't pan out.

"We initially tested adding Java 8 support via the Jack toolchain," Lau said. "Over time, we realized the cost of switching to Jack was too high for our community when we considered the annotation processors, bytecode analyzers and rewriters impacted. Thank you for trying the Jack toolchain and giving us great feedback. You can continue using Jack to build your Java 8 code until we release the new support. Migrating from Jack should require little or no work."

While there will be no immediate impact on Android developers as the deprecation process proceeds, Lau said the team wanted to get the news out early. Coders can continue to use the same tools and plug-ins until Java 8 native support is built into the Android Studio IDE "in the coming weeks."

He promised more details on the team's efforts to incorporate Java 8 language features natively in the Android system when the IDE support is released.

One entity that might be affected is Bugsnag, a development-oriented company that just last week announced "Support for Android Jack -- Code obfuscation with ProGuard and Jack." The blog post said: "The Jack Toolchain now offers more functionality than the traditional Android compiler and looks likely to be the default in the future."

About the Author

David Ramel is an editor and writer for Converge360.