Groovy 4 oder Kotlin: Warum der Sprachwechsel beim Upgrade weniger kostet als gedacht

Ab der nächsten Versionsstufe springt die Plattform von Java 8 auf Java 17 beziehungsweise 21 und von Groovy 2.4 auf Groovy 4. Später kommt der Wechsel von javax auf jakarta dazu. Der alte Code muss also ohnehin angefasst werden, egal wie man sich entscheidet. Damit lautet die Frage nicht «Kotlin oder nichts», sondern: anheben oder neu schreiben.
Für Groovy sprechen echte Gründe. Der Aufwand ist zunächst geringer, weil die Struktur des Codes bleibt und die Fachlogik angepasst statt neu aufgebaut wird. Groovy ist ausserdem die eingebaute Skriptsprache der Plattform, Aktionen und Vorlagen funktionieren damit ohne Umweg, und man kommt schneller zu einem ersten lauffähigen Stand. Für ein System, das in zwei Jahren abgelöst wird oder kaum noch Änderungen braucht, sind das gute Gründe.

Pro Funktion lassen sich fünf Bestandteile schätzen: die Analyse (was gehört dazu, worauf baut sie auf, wer nutzt sie), die Umsetzung, der Test, die Abnahme beim Kunden und Zuschläge für Projektkoordination und Reserve. Ein Durchlauf aus Prüfung und Korrektur bei der Abnahme dauert rund zwei Wochen.
Der Mehraufwand für Kotlin entsteht fast ausschliesslich bei der Umsetzung. Analyse, Test und Abnahme fallen auf beiden Wegen an. Einarbeitung ist kein nennenswerter Posten, weil Kotlin im selben System bereits in sechs Plugins läuft. Auch beim Tooling gibt es kaum Unterschiede, denn die Plugins müssen auf beiden Wegen gegen die neue Plattformversion neu gebaut werden.
Beim ersten Vorkonzept lag der geschätzte Mehraufwand für Kotlin deutlich höher als heute. Damals war der Groovy-Weg noch nicht genau bekannt. Die Bestandsaufnahme im Code und in der Datenbank hat gezeigt, dass er mehr Arbeit verlangt als angenommen. Für die tragenden Teile gibt es keine automatisierten Tests, die müssen auf beiden Wegen erst entstehen. Die Pflichtarbeiten des Herstellers fallen ebenfalls auf beiden Wegen an: Groovy 4, neuer Namensraum, Umstellung der Dateien auf UTF-8, neuer Texteditor, neuer Suchindex.
Dazu kommt, dass Groovy viele Fehler erst zur Laufzeit meldet. Nach dem Sprung auf Groovy 4 muss deshalb jede Funktion vollständig geprüft werden, nicht nur die geänderten. Die Bestandsaufnahme hat ausserdem Schwächen im alten Code aufgedeckt, etwa Fehler, die stillschweigend passieren, ohne dass jemand eine Meldung erhält. Auch die müssen auf beiden Wegen behoben werden. Gleichzeitig ist der Teil, der überhaupt neu geschrieben werden muss, kleiner geworden: Mehrere alte Funktionen werden nachweislich nicht mehr genutzt und entfallen, andere sind bereits in Kotlin umgesetzt.

Sascha, Softwareentwickler und technischer Lead bei Batix:«Der Mehraufwand pro Zeile Kotlin ist nicht kleiner geworden. Kleiner wird sein Anteil am Ganzen, weil der Sockel, den beide Wege gleich viel kostet, deutlich gewachsen ist.»

Ein Zwischenschritt auf die nächste Version der heutigen Linie hätte einen eigenen Testzyklus beim Kunden gekostet. Er hätte ausserdem auf eine Version geführt, die selbst keine Updates mehr erhält. Der eigentliche Umbruch mit neuer Java-Version, Groovy 4 und dem Wechsel auf Docker kommt danach ohnehin. Was ein Zwischenschritt gebracht hätte, etwa ein Prüfwerkzeug für den Namensraum oder einen Vorabtest mit Groovy 4, lässt sich genauso auf der neuen Umgebung erreichen.
Deshalb wird das Zielsystem auf einem neuen Server parallel aufgebaut, Funktion für Funktion und mit Prüfung nach jedem Schritt. Die Produktion läuft unterdessen unverändert weiter, umgeschaltet wird erst nach der Abnahme.
Das Vorgehen hat einen Preis, und der gehört dazu. Die Produktion bleibt länger auf dem alten Stand und hat bis zur Umschaltung dessen bekannte Schwächen. Dem begegnet man mit gezielten Sofortmassnahmen, statt den Altbestand einmal zwischendurch anzuheben. Am Ende steht eine grosse Umschaltung, die sich mit einer Generalprobe und einer Rückfallbereitschaft entschärfen lässt: Die alte Umgebung bleibt lauffähig, bis auf der neuen alle Abläufe einmal erfolgreich gelaufen sind und der Kunde abgenommen hat. Und zwei Umgebungen kosten doppelt, allerdings nur bis zur Umschaltung.

Aus dem Beispiel lassen sich fünf Fragen ableiten, die ein Entscheider vor der Wahl klären sollte.
Erstens: Muss der Code ohnehin angefasst werden? Steht ein Plattformwechsel an, schrumpft der Unterschied zwischen Anheben und Neuschreiben deutlich.
Zweitens: Gibt es Tests? Ohne Testnetz ist es ein grosser Vorteil, wenn der Compiler Fehler findet, bevor sie im Betrieb auftauchen.
Drittens: Wie lange lebt das System noch, und wie oft wird es geändert? Der Mehraufwand fällt einmal an, der Nutzen bei jedem Change Request erneut, weil Änderungen im neuen Code schneller und sicherer umzusetzen sind.
Viertens: Wohin entwickelt sich die Plattform? Der Hersteller der Plattform empfiehlt Kotlin für Plugins und kündigt an, alte Bausteine in der nächsten Hauptversion zu entfernen. Wer auf Groovy bleibt, riskiert einen zweiten Umbau.
Fünftens: Wo liegt das Wissen? Gewachsener Groovy-Code mit plattformeigenen Bausteinen ist Spezialwissen weniger Personen, Kotlin ist verbreitet.

Sascha zur Gewichtung:«Wenn der Code ohnehin angefasst werden muss und das System noch Jahre weiterentwickelt wird, ist Kotlin die bessere Wahl. Das Anheben auf Groovy ist sinnvoll, wenn ein System absehbar abgelöst wird oder kaum noch Änderungen braucht. Dann zählt der geringere Startaufwand mehr als die langfristige Wartbarkeit.»