Seite 3: Explodierende Testmatrix

Inhaltsverzeichnis

Wer Software ausliefert und sicherstellen möchte, dass sie auf verschiedenen Java-Versionen funktioniert, kommt nicht umhin auf allen zu testen. Aber auch wer volle Kontrolle über seine Deployments hat, wie bei der Entwicklung einer klassischen Webanwendung oder der Verwendung von jlink, sollte in Betracht ziehen, auf mehreren Java-Version zu bauen, um frühzeitig herauszufinden, wenn Probleme auftreten. Der ansatzlose Sprung von Java 11 zu 17 kann schwierig sein, wenn man Migrationsprobleme bekommt, aber nicht weiß, welche Java-Version sie ausgelöst hat.

Um auf verschiedenen Versionen zu bauen und bei Bedarf dann auch in einer konkreten Version Fehler zu analysieren, muss man möglichst reibungslos zwischen ihnen wechseln können. Alle populären IDEs, Build-Tools und CI-Server machen das möglich, aber besonders benutzerfreundlich ist das nicht immer. Es lohnt sich für Entwickler, sich mit den Features intensiv auseinanderzusetzen und bei Bedarf Feature Requests zu erstellen, wenn es einfacher sein könnte.

Automatisierung spielt ebenfalls eine große Rolle. Entwickler machen sich das Leben deutlich einfacher, wenn man dafür sorgt, dass man mit ein paar Mausklicks oder ein paar Zeilen Konfiguration einen neuen CI-Build erstellen kann. Einen solchen Automatisierungsgrad zu erreichen hat viele Vorteile – ohne große Umstände auf verschiedenen Java-Versionen gleichzeitig bauen zu können, ist nur einer davon.

Eine Konsequenz von mehreren Builds ist allerdings gestiegener Ressourcenverbrauch. Jeden Build statt auf einer auf drei Java-Versionen auszuführen verdreifacht natürlich den Bedarf nach Rechenleistung. Wenn das zu aufwendig oder teuer ist, kann man in Betracht ziehen, für manche Java-Versionen nur einmal nächtlich zu bauen. Um nicht nur auf Sicht zu fahren, sollte man neben dem üblichen CI-Build aber zumindest einmal täglich einen Build auf der aktuellen Java-Version laufen lassen.

Wenn dafür außerdem noch Early Access Builds im Einsatz sind, derzeit zum Beispiel schon für Java 12 verfügbar, kann man sogar helfen, Bugs im JDK aufzudecken, und damit zur Gesundheit des Ökosystems beitragen.

Fragmentiertes Ökosystem

Manche haben die Sorge, dass der Spalt zwischen Java 8 und 9 so tief ist wie der zwischen Python 2 und 3. Diejenigen möchte der Autor beruhigen: Das ist nicht der Fall. Alle weitverbreiteten IDEs und Build-Tools sowie alle großen Frameworks und Bibliotheken unterstützen Java 9, und wo das nicht der Fall ist, arbeitet das Team meist hart daran. Dem Autor ist kein Projekt bekannt, das entschieden hat, vorerst nur Java 8 zu unterstützen.

Was allerdings etwas auf sich warten lässt, ist die weitläufige Verwendung des Modulsystems. Bisher haben nur wenige Projekte angefangen, Module auszuliefern. Dass ist zu erwarten gewesen, denn bevor Java 9+ Mindestvoraussetzung wird, ergibt es für ein Projekt nicht viel Sinn, Module zu erstellen. Und da bisher nur wenige Anwendungen auf Java 9+ laufen, warten die großen Bibliotheken und Frameworks mit der Modularisierung noch etwas.