Metas Erfahrungen und Erkenntnisse aus der groß angelegten Umstellung von Java auf Kotlin

• Meta stellt im Rahmen eines mehrjährigen Projekts seine Android-Codebasis von Java auf Kotlin um
• Das Unternehmen verwaltet inzwischen eine der größten Android-Codebasen der Welt und hat bereits mehr als die Hälfte erfolgreich nach Kotlin konvertiert
  • Meta verfolgt seit 2020 eine Kotlin-first-Entwicklungsstrategie
• Gründe für die Konvertierung des gesamten Codes:
  • Um die Vorteile von Kotlin in Bezug auf „höhere Produktivität“ und „Null-Sicherheit“ maximal zu nutzen, entschied sich Meta, auch die bestehenden zehn Millionen Zeilen Java-Code zu konvertieren
  • Stärkung der Null-Sicherheit und Lösung von Problemen in einer gemischten Codebasis
    • Mixed Compilation (gleichzeitiges Kompilieren von Java und Kotlin) verlangsamt den Build am stärksten
    • Verbleibender Java-Code verursacht weiterhin Probleme bei der Null-Sicherheit: Nicht null-sicherer Java-Code ist im Abhängigkeitsgraphen eine potenzielle Ursache für NullPointerException (NPE)
    • Kotlin gewährleistet Null-Sicherheit durch Laufzeitprüfungen

Automatisierungsprozess

• Anfangs wurde wiederholt das J2K-Konvertierungstool der IntelliJ IDE ausgeführt
  • In Metas großer Codebasis wären dafür mehr als 100.000 Klicks nötig gewesen, und jeder Lauf dauerte mehrere Minuten
  • Dadurch erwies sich dieser Ansatz als nicht skalierbar und ineffizient
• Entwicklung des Automatisierungstools: Kotlinator
• Sechsstufiger Konvertierungsprozess
  1. Deep Build: Der zu konvertierende Code wird gebaut, damit die IDE alle Symbole auflösen kann, einschließlich Third-Party-Abhängigkeiten und generiertem Code
  2. Preprocessing: Auf Basis von Metas eigenem Tool Editus. Enthält rund 50 Schritte, darunter Null-Sicherheits- und Abhängigkeitsbehandlung sowie Workarounds für J2K
  3. Headless J2K: J2K wurde so angepasst, dass es in einer Serverumgebung ausgeführt werden kann
  4. Postprocessing: Rund 150 Schritte für Android-spezifische Änderungen, Null-Sicherheit und die Anwendung des Kotlin-Stils
  5. Linters: Kontinuierliche Verbesserung der Konvertierungsqualität durch automatische Korrekturen
  6. Build Error-based Fixes: Analyse von Build-Fehlern und Anwendung zusätzlicher Korrekturen

J2K headless ausführen

• Anpassung von J2K für die Remote-Ausführung:
  • J2K war eng an die IntelliJ IDE gekoppelt, wodurch ein unabhängiger Betrieb schwierig war
  • Zunächst wurde erwogen, die IntelliJ-Testumgebung zu nutzen; nach Rücksprache mit dem J2K-Experten von JetBrains (Ilya Kirillov) erfolgte jedoch der Wechsel zu einem headless Inspections-Ansatz
  • Umsetzung über ein IntelliJ-Plugin, das die Klasse ApplicationStarter erweitert und die Klasse JavaToKotlinConverter von J2K aufruft
• Vorteile des Headless-Ansatzes
  • Lösung lokaler IDE-Probleme: Entwickler müssen nicht mehr selbst Buttons in der IDE anklicken
  • Gleichzeitige Konvertierung mehrerer Dateien: Verarbeitung großer Dateimengen wird möglich
  • Weniger Zeitaufwand: Die eigentliche Konvertierungszeit stieg zwar auf etwa 30 Minuten, der Zeitaufwand für Entwickler sank jedoch deutlich
  • Unterstützung für Builds und Fehlerbehebung: Zeitintensive, aber nützliche Schritte wie Korrekturen nach dem Build lassen sich remote automatisiert ausführen
• Automatisierung und Code-Review
  • Mithilfe interner Systeme erstellt Meta tägliche Batch-Jobs:
  • Auf Basis benutzerdefinierter Kriterien werden im Batch diffs erzeugt (Metas Version von Pull Requests)
  • Reviewer werden automatisch zugewiesen, Tests und Validierungen ausgeführt und der schließlich freigegebene diff ausgerollt
• Bereitstellung einer Web-UI: Entwickler können die Konvertierung bestimmter Dateien oder Module remote auslösen
• Festlegung der Konvertierungsreihenfolge
  • Es wird keine bestimmte Reihenfolge erzwungen:
    • Aktiv entwickelte Dateien werden bevorzugt bearbeitet
    • Kotlinator verarbeitet den Abhängigkeitsgraphen automatisch und behebt Kompatibilitätsprobleme in externen Dateien
    • Beispiel: foo.getName() wird automatisch zu foo.name aktualisiert

Sonstiges

• Hinzugefügte benutzerdefinierte Preprocessing- (Java->Java) und Postprocessing-Schritte (Kotlin->Kotlin)
• Verbesserung der Konvertierungsqualität durch Metas internes Tool Editus und die PSI-Bibliothek von JetBrains
• Nullsafe und NullAway

Gegenwart und Zukunft der Kotlin-Konvertierung

• Mehr als die Hälfte von Metas Android-Java-Code wurde bereits nach Kotlin konvertiert (oder der entsprechende Code teilweise gelöscht)
• Doch die einfache Hälfte ist geschafft:
  • Die verbleibende Arbeit ist komplex und umfangreich
  • Für eine vollständig automatisierbare Konvertierung müssen zusätzliche benutzerdefinierte Schritte ergänzt oder Verbesserungen an J2K beigetragen werden
  • Bei halbautomatischen Konvertierungen ist das Ziel, Kotlinator so weiterzuentwickeln, dass reibungslose und sichere Deployments möglich werden
• Meta geht davon aus, dass auch andere Unternehmen vor ähnlichen Problemen bei der Umstellung von Android-Code stehen
• Meta teilt die bei der Verbesserung und Optimierung der Konvertierungstools gewonnenen Lösungen
• Aufruf zur Zusammenarbeit:
  • Diskussion mit anderen Entwicklern im #j2k-Kanal des Kotlinlang-Slack
  • Durch das Teilen eigener Fälle und Lösungen lässt sich gemeinsam eine bessere Konvertierungserfahrung aufbauen