Seit Kurzem wird Java Runtime kostenpflichtig von Oracle lizenziert. Dabei gibt es auch eine kostenlose Variante: OpenJDK. Wir von BusinessCode raten unseren Kunden, darauf umzustellen. Doch zunächst wollen wir einmal genau hinzuschauen und unsere Erfahrungen zusammenfassen. Unser Kollege Eugen Plischke hat sich ausführlicher mit der Umstellung befasst und uns seine Erfahrungen aufgeschrieben.
Es gibt 2 Wege, ein Projekt auf Java12 „umzustellen“
(A): Kompatibilität herstellen
Einige Bestandteile, die zum Kern von Java Runtime gehört haben, werden mit Java12 nicht mehr ausgeliefert, sodass sie manuell dem Projekt hinzugefügt werden müssen. Viele dieser Abhängigkeiten wurden einzeln entwickelt und verteilt, mit jeweils voneinander unabhängigen Versionsnummern. Je nachdem, welche Features davon im Projekt verwendet werden, müssen diese (Libraries) jeweils einzeln importiert werden.
Diese Libraries wiederum haben eigene Lifecycle. Sie werden behandelt wie „normale“ third-party Libs und müssen in der Version bezogen werden, die kompatibel zum Projektcode ist. Ferner werden im Projekt auch weitere, Kern-Fremde Libraries verwendet. Diese besitzen natürlich auch Abhängigkeiten zu diesen Java-Modulen, die vorher zum Java-Kern gehört haben und jetzt einzeln verteilt werden. Die Kompatibilität auf dieser Ebene kann nicht festgestellt werden: Alle Punkte, die während der Kompilierzeit zu einem Fehler führen, können angegangen und angepasst werden. Alle anderen Inkompatibilitäten treten erst während der Laufzeit auf.
Fazit: Es muss eigentlich jede Funktion getestet werden.
Der Projektcode selbst, sofern dieser mit Java8 lief, läuft auch unter Java12, so in unserem Fall. Das können wir nicht generell behaupten, da es davon abhängt, inwieweit man die Bestandteile nutzt, die vorher zum Java-Kern gehört haben und jetzt eigenständig sind und eventuell Änderungen in der API aufweisen.
Java hat ein neues Feature eingeführt: Module. Möchte man diese nutzen, muss man den Projektcode erweitern, um die Module zu beschreiben und ggf. den Projektcode anders zu organisieren. Das setzt jedoch voraus, dass andere third-party libs einem nicht in die Quere kommen und ebenfalls zum neuen Module-Standard kompatibel sind. Bei Libraries, die jetzt aus dem Java-Kern herausgezogen sind, ist dies der Fall, bei den anderen third-party libs nicht. Java bringt dafür eine Rückwärtskompatibilität mit, die bei uns allerdings nicht funktionierte. Aktuell wissen wir noch nicht, warum dies so ist, und ob es nicht einfach ein Eclipse-Bug ist.
Wenn der Projektcode im Java12-Target (Zielumgebung) kompiliert wird, muss dieser zwingend den neuen Modul-Standard umsetzen. Um den Modul-Standard zu deaktivieren, muss das Kompiliertarget auf Java8 gesetzt werden. In diesem Fall kann immer noch mit Java12 kompiliert werden und das Ergebnis läuft auch auf der Java12 Runtime.
(B): Java12 Standard einführen
Des Weiteren muss noch die Entwicklungsumgebung – (Eclipse) – in der Lage sein, mit dem neuen Standard zu arbeiten. Selbst das war bis vor ca. KW27 ein Problem. Eclipse hatte Bugs und verhinderte ein sauberes Arbeiten am Projektcode.
Anschließend gibt es noch die Buildchain, also das Packaging des Projekts. Das ist, je nachdem, ob wir Gradle oder ANT verwenden, die nächste Baustelle.
Gradle:
Hier muss man auf die Gradle Version 5.2 hochziehen. Diese ist wiederum nicht vollständig kompatibel zu Version 4, die wir bisher in einigen Projekten eingesetzt haben. Das heißt, der Projektcode der Buildchain muss angepasst werden.
ANT:
Auch hier muss die vorhandene ANT Installation kompatibel zu Java12 sein. Bei ANT 1.9 haben wir keine Probleme auf Java12 festgestellt. Der Projektcode muss erweitert werden, um die Kompilierung in Target Java8 zu erzwingen.
Ansonsten habe ich ein Dokument erstellt, das die Schritte der Umstellung protokolliert.
Sie haben noch weitere Fragen? Dann wenden Sie sich an uns, wir helfen Ihnen gerne!
Foto: Eugen Plischke