Von Java nach Kotlin: Meta berichtet von zehn Millionen Codezeilen

In den vergangenen Jahren hat Meta die Android-Apps für Facebook, Instagram und Co von Java auf Kotlin umgestellt und teilt nun die gemachten Erfahrungen.

In Pocket speichern vorlesen Druckansicht 60 Kommentare lesen
Kotlin

(Bild: Shutterstock)

Lesezeit: 6 Min.
Inhaltsverzeichnis

In einem Blogbeitrag berichtet Meta von den Erfahrungen bei der Umstellung der Android-Apps von Java auf Kotlin. Laut eigenen Angaben hat das ehemals als Facebook bekannte Unternehmen inzwischen eine Codebasis mit über 10 Millionen Zeilen Kotlin-Code. Laut dem Facebook-Engineering-Blog weisen die Android-Apps für Facebook, Messenger und Instagram inzwischen jeweils über eine Million in Kotlin verfasste Codezeilen auf. Für die Migration setzte es auf unter anderem auf den Java to Kotlin Converter von JetBrains.

Google hat 2017 Kotlin offiziell als Alternative zu Java für die Android-Entwicklung erklärt und in die IDE Android Studio aufgenommen. Inzwischen ist die Programmiersprache die erklärte erste Wahl für Android-Apps, und aktuelle Techniken wie Jetpack Compose setzen ausschließlich auf Kotlin. Dank dieser Entwicklungen und den Vorteilen von Kotlin gegenüber Java ist der Wechsel der Programmiersprache zum Entwickeln von Android-Apps für viele Unternehmen attraktiv.

Meta nennt in dem Blogbeitrag über die Erfahrungen bei der Migration vier wesentliche Vorteile von Kotlin gegenüber Java. Der Maßstab für Letzteres ist dabei nicht das aktuelle Java 19, sondern Java 11, das die Basis für die Android-Entwicklung darstellt.

Als erster Grund steht der Umgang mit Nullability und damit das Verhindern von Problemen mit dem "Billion Dollar Mistake" auf dem Plan: Kotlin verhindert Null-Pointer-Exceptions bereits beim Kompilieren, da es von Haus aus Vorgaben hat, Typen als Nullable zu deklarieren, während standardmäßig eine Zuweisung von null untersagt ist. Auf Nullable-Typen darf wiederum kein direkter Aufruf erfolgen – es sei denn Übermütige verwenden den !!-Operator.

Der zweite Grund ist, dass Kotlin deutlich mehr Wege für die funktionale Programmierung bietet als Java. Das ist gleichzeitig eine der Grundlagen für kürzeren, kompakteren Code, was aus Metas Sicht als drittes Argument für Kotlin spricht.

Schließlich bietet Kotlin Type-safe Builders, die sich als Grundlage für Domain-specific Languages (DSLs) verwenden lassen. Meta führt als Beispiel das Überführen von Definitionen wie Android XML in Kotlin-Code an, weist aber gleichzeitig auf das Risiko des Overengeneering bei zu ambitionierten DSL-Projekten hin.

Bei der Entscheidung, ob die Teams nur neuen Code in Kotlin schreiben und mit vorhandenem Java-Code verknüpfen sollten oder die vorhandene Codebasis möglichst vollständig zu Kotlin zu migrieren, hat sich Meta für letztere Option entschieden. Das war zwar zum Start deutlich aufwendiger und mit einigen Hürden verbunden, aber aus Sicht von Meta deutlich besser, als sich dauerhaft den Limitierungen durch das Zusammenspiel der beiden Sprachen auszusetzen.

Offenbar sind beim Start der Migration einige Blockaden aufgetaucht, die es zu beseitigen galt. Dazu hat Meta unter anderem eigene Tools wie den Bytecode-Optimierer Redex angepasst und neue Werkzeuge wie das deterministische Formatierungstool für Kotlin Ktfmt geschrieben.

Für die Migration hat Meta eine Pipeline mit drei Schritten etabliert: Im ersten Schritt steht die Vorbereitung der Java-Pakete auf die Migration an, unter anderem mit Blick auf die hauseigenen Tools.

Der zweite Schritt ist die Umwandlung des Java-Codes in Kotlin mit dem Java to Kotlin converter (J2K), der Bestandteil von IntelliJ IDEA und dem darauf aufsetzenden Android Studio ist. Bei Meta läuft letztere IDE im Headless-Mode, um das Konvertieren mit J2K über ein Skript durchzuführen.

Schließlich passt das Postprocessing die Kotlin-Dateien an die Voraussetzungen bei Meta an, unter anderem mit automatisierten Refactorings und dem Anpassen von Annotationen für JUnit.

Das Zusammenspiel mit dem Werkzeug für Unit-Tests nennt Meta als ein Beispiel für die anfänglichen Herausforderungen bei der automatisierten Umwandlung, da J2K dabei nicht die Details von JUnit kennt und damit unter anderem in Java öffentliche Felder nach der Umwandlung in Kotlin privat sind.

Insgesamt zieht Meta eine positive Bilanz aus der Umstellung. Abgesehen davon, dass unter anderem die strikten Nullability-Vorgaben Fehlerquellen reduzieren und Kotlin-Code insgesamt als übersichtlicher gilt, betrachtet der Blogbeitrag einige Faktoren wie Größe und Performance.

Die Codebasis ist insgesamt schlanker geworden, da unter anderem Null-Checks entfallen oder sich wiederholende Loops durch Standard-Kotlin-Methoden ersetzen lassen, die Lambdas übernehmen. Insgesamt ist die Zahl der Codezeilen nach der Umstellung auf Kotlin laut Metas Angaben um elf Prozent gesunken, einige Dateien mit viel Boillerplate-Code sind wohl um die Hälfte geschrumpft.

Bei der Ausführungsgeschwindigkeit gibt es wohl weder Vor- noch Nachteile: Der Kotlin-Code hat mehr oder weniger dieselbe Performance wie Java. Die Android-Pakete (APKs) sind wohl nach der Migration etwas größer als davor, was vor allem am Einbinden der Kotlin-Standard-Library liegt. Diese hat Meta für die Fälle vermieden und stattdessen auf Java-Methoden gesetzt, in denen es auf jedes KByte ankommt.

Ein Nachteil sind die neuen Build-Zeiten, die wohl erkennbar länger sind als zuvor. Das Unternehmen arbeitet an einigen Methoden, die unter anderem das Verarbeiten von Annotationen beschleunigen soll. Außerdem kann das Build-System Buck im Zusammenspiel mit Java Source-only ABI-JARs (Application Binary Interface Java Archive) für Binaries erstellen, die auf das Kompilieren der Dependencies verzichten. Das Team entwickelt derzeit eine Umsetzung der Source-only ABI-JARs für Kotlin-Code.

Alle Tools und Libraries, die Meta erstellt, um die Migration nach Kotlin zu vereinfachen, will das Unternehmen laut dem Blogbeitrag mittelfristig der Community zur Verfügung stellen.

Weitere Details lassen sich dem Engineering-Blog bei Facebook entnehmen.

(rme)