Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Porting Million Lines of Code from Java to Kotlin at Meta

Porting Million Lines of Code from Java to Kotlin at Meta


Meta has been at work to port their Android codebase from Java to Kotlin. In the process, they have learned a number of lessons of general interest and developed a few useful approaches, explains Meta engineer Omer Strulovich.

Meta's decision to adopt Kotlin for their Android apps was motivated by Kotlin advantages over Java, including nullability and functional programming support, shorter code, and the possibility of creating domain specific languages. It was also clear to Kotlin engineers that they had to port to Kotlin as much of their Java codebase as possible, mostly to prevent Java null pointers from creeping into the Kotlin codebase and to reduce the remaining Java code requiring maintenance. This was no easy task and required quite some investigation at start.

A first obstacle Meta engineers had to overcome came from several internal optimization tools in use at Meta that did not work properly with Kotlin. For example, Meta had to update the ReDex Android bytecode optimizer and the lexer component of syntax highlighter Pygments, and built a Kotlin symbol processing (KSP) API, used to create Kotlin compiler plugins.

On the front of code conversion proper, Meta engineers opted to use Kotlin official converter J2K, available as a compiler plugin. This worked quite well except for a number of specific frameworks, including JUnit, for which the tool lacks sufficient knowledge to be able to produce correct conversions.

We have found many instances of these small fixes. Some are easy to do (such as replacing isEmpty), some require research to figure out the first time (as in the case of JUnit rules), and a few are workarounds for actual J2K bugs that can result in anything from a build error to different runtime behavior.

The right approach to handle this cases consisted in a three-step pipeline to first prepare Java code, then automatically run J2K in a headless Android Studio instance, and finally postprocess the generated files to apply all required refactoring and fixes. Meta has open sourced a number of those refactorings to help other developers to accomplish the same tasks.

These automations do not resolve all the problems, but we are able to prioritize the most common ones. We run our conversion script (aptly named Kotlinator) on modules, prioritizing active and simpler modules first. We then observe the resulting commit: Does it compile? Does it pass our continuous integration smoothly? If it does, we commit it. And if not, we look at the issues and devise new automatic refactors to fix them.

Thanks to this approach, Meta has been able to port over 10 million lines of Kotlin code, allowing thus the majority of Meta Android engineers to switch to Kotlin for their daily tasks. The process also confirmed a number of expected outcomes, including shorter generated code and unchanged execution speed. On the negative side, though, Kotlin compiler proved significantly slower than Java's. This opened up a new front for optimization by using KSP for annotation processing and improving Java stub generation and compile times, which is still an ongoing effort.

Do not miss the original article about Meta's journey to adopt Kotlin if you are interested in the full details.

About the Author

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Treatment is worse than the disease

    by Jukka Koskimäki,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It seems, that Meta engineers have reached the situation, where they are aiming to repair f.ex null pointer problems, which is, after all, quite targetable problem in codebase, but now they have full hand of diverse problems and challenges here and there and everywhere!

    And also, some the claims in the original text seems to be quite flimsy, like one about functional programming would be somehow fundamentally better in Kotlin, and another that Java "... comes at the cost of more anonymous objects", which is actually on the contrary based on Kotlin's own texts.

    Also, the claim that "..shorter code is also more explicit" is just not true in general sense.

  • And this is why Meta is hemorrhaging money...

    by Sam King,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Replacing millions of lines of easily-supportable code in a mainstream language with identical code in a different language "just because" is a great way to waste colossal amounts of money.

  • What a bizarre decision

    by Steve Zara,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This makes no sense. Java compiles and runs perfectly well on Android, and as Google have shown, can form a solid basis for portable mobile code that runs on iOS too. Porting to another language that is more platform-specific is rarely a good decision. If there is a specific need for Kotlin, write new code in Kotlin.

  • Re: Treatment is worse than the disease

    by Sergio De Simone,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    All great points, Jukka. I did not attempt to echo or support Meta's reasoning about Kotlin superiority over Java as this is clearly a highly debatable issue. Happy to see my article did not convey the wrong idea. My aim was reporting about Meta's experience attempting to port their Java codebase to Kotlin, which may appear sensible or not, but is surely an "interesting" experiment. Thanks for your contribution, which brings up an important facet of what "interesting" could actually mean.

  • Re: And this is why Meta is hemorrhaging money...

    by Sergio De Simone,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hey, Sam, you sum up in a really concise form a very reasonable point of view. Discussions over languages and the advantages they bring may become heated and are often driven by pure hype. In this case, thanks to Meta's effort, we can have a more solid base to understand whether porting a Java codebase to Kotlin, with its costs and benefits, makes sense or not. I tend to side with your view, i.e., having tons of money is an important pre-requisite to attempt that. Thanks.

  • Re: What a bizarre decision

    by Sergio De Simone,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for you comment, Steve. I can see how Goggle making Kotlin the preferred language for Android development has somewhat backed a kind of expectation that Kotlin should be the way to got for Android development. Now, there are surely cases where I would support the idea of going from Java to Kotlin, for example to use Jetpack Compose, but that is just my personal opinion based on my experience. But it is surely true that the decision as to whether going full-Kotlin or have a mixed codebase is one that should be accurately assessed. Even more so after learning about Meta's experience, we could say. Thanks.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p