In todays Nuggets we talk about the Kotlin Compiler, the D8 Dexer and the R8 shrinker.

Kotlin is a multiplatform language. With respect to compilation, the current compiler has one frontend and 3 backends. The frontend of compiler is the part which checks things like correctness of syntax, type checking, type inference etc whereas the backend generates the machine or Intermediate Representation (IR) code to run for the respective execution environment. Kotlin supports three different execution environments, Kotlin JVM, Kotlin Javascript and Kotlin Native for the three platforms on which it is supported. For android, the backend generates Java byte code for the Kotlin JVM environment, which is then converted to dex format by D8. For Java Script execution environment it converts Kotlin into equivalent Java source files and for Kotlin native it produces LLVM. Most of the compilers time goes into frontend ie around 80% of the compilation time.

Once the Kotlin or Java compiler generates the .class files (Java Byte Code), D8 compiles the Java bytecode into optimized DEX files (Dalvik Executable files) and includes debug information that you can use to debug your code during runtime. Earlier Dx was used for the same purpose which has been replaced by new D8.

A problem specific to Android has been that different versions of Android may use different version of Open JDK underneath and in order to support the newer Java 1.8 features to run on all Android devices D8 does something called desugaring which converts useful language features into bytecode that can run on all the Android platform. Inside of the D8 project, there are template implementations of each API that it can backport. For backporting Java 1.8 features, D8 replaces the call to original Java 1.8 libraries with calls to its own version of Java 1.8 libraries which it ships with the generated code so that even in the older Android platforms where the Java 1.8 libraries are missing, the code can run as it will be using the shipped D8 version of Java 1.8 libraries. In general, D8 doesn’t perform optimization. It may choose to use Dalvik bytecodes which more efficiently represent the intent of Java bytecodes, or, in the process of desugaring language features, it may choose to optimize the desugared code it is generating. Aside from these very localized changes, D8 otherwise performs a direct translation.

R8 is a version of D8 that also performs optimization. It’s not a separate tool or codebase, just the same tool operating in a more advanced mode. Where D8 first parses Java bytecode into its own intermediate representation (IR) and then writes out the Dalvik bytecode, R8 adds optimization passes over the IR before its written out. Earlier, Proguard would process the .class files, compact them and then these compacted .class files would be fed to Dex/D8 processor to convert them into .dex files, R8 merges these two steps, and takes in .class files, returning .dex files. R8 would do shrinking like Proguard and would remove all unused resources and class files from app and its dependent libraries that cannot be reached from the app code including resources. This might also remove some files that are referenced through reflection as R8 is not able to find direct references and hence we have to use specifically keep rules in proguard to explicitly state R8 to keep these files.