Meta has been at work to port their Android codebase from Java to Kotlin. Within the course of, they’ve realized quite a lot of classes of normal curiosity and developed just a few helpful approaches, explains Meta engineer Omer Strulovich.
Meta’s choice to undertake Kotlin for his or her Android apps was motivated by Kotlin benefits over Java, together with nullability and practical programming help, shorter code, and the potential of creating area particular languages. It was additionally clear to Kotlin engineers that they needed to port to Kotlin as a lot of their Java codebase as potential, largely to stop Java null pointers from creeping into the Kotlin codebase and to cut back the remaining Java code requiring upkeep. This was no simple activity and required fairly some investigation at begin.
A primary impediment Meta engineers needed to overcome got here from a number of inner optimization instruments in use at Meta that didn’t work correctly with Kotlin. For instance, Meta needed to replace the ReDex Android bytecode optimizer and the lexer part of syntax highlighter Pygments, and constructed a Kotlin image processing (KSP) API, used to create Kotlin compiler plugins.
On the entrance of code conversion correct, Meta engineers opted to make use of Kotlin official converter J2K, out there as a compiler plugin. This labored fairly effectively apart from quite a lot of particular frameworks, together with JUnit, for which the software lacks adequate information to have the ability to produce appropriate conversions.
We have now discovered many situations of those small fixes. Some are simple to do (comparable to changing isEmpty), some require analysis to determine the primary time (as within the case of JUnit guidelines), and some are workarounds for precise J2K bugs that may end up in something from a construct error to totally different runtime conduct.
The correct strategy to deal with this circumstances consisted in a three-step pipeline to first put together Java code, then robotically run J2K in a headless Android Studio occasion, and eventually postprocess the generated recordsdata to use all required refactoring and fixes. Meta has open sourced quite a lot of these refactorings to assist different builders to perform the identical duties.
These automations don’t resolve all the issues, however we’re in a position to prioritize the most typical ones. We run our conversion script (aptly named Kotlinator) on modules, prioritizing energetic and easier modules first. We then observe the ensuing commit: Does it compile? Does it go our steady integration easily? If it does, we commit it. And if not, we have a look at the problems and devise new computerized refactors to repair them.
Due to this strategy, Meta has been in a position to port over 10 million strains of Kotlin code, permitting thus nearly all of Meta Android engineers to modify to Kotlin for his or her day by day duties. The method additionally confirmed quite a lot of anticipated outcomes, together with shorter generated code and unchanged execution pace. On the unfavorable aspect, although, Kotlin compiler proved considerably slower than Java’s. This opened up a brand new entrance for optimization through the use of KSP for annotation processing and enhancing Java stub technology and compile instances, which remains to be an ongoing effort.
Don’t miss the unique article about Meta’s journey to undertake Kotlin if you’re within the full element.
