Ich habe mich in den letzten Wochen intensiver mit der neuesten Java-Version (22) beschäftigt, habe mir die Änderungen angeschaut, habe mir durchgelesen, was in Preview kommt und wie es mit Java wohl weitergeht. Ich habe bei Java 21 nachgeschaut, was dort im Preview war und was nun in der Version 22 enthalten ist. Ich habe ein paar Programmzeilen geschrieben, herumexperimentiert und mich mit anderen Programmierern ausgetauscht. Und nun? Zurück zum Projekt. Bei dem von Java 22 gar keine Rede sein kann. Dort arbeitet man noch mit Java 13. Und das wird sich auch in den nächsten Jahren nicht ändern.
Warum aber arbeiten wir immer mit veralteten Java-Version?
Es ist unwahrscheinlich, dass ich in den nächsten 10 Jahren mit Java 22 arbeiten werde. Viele Projekte zu denen ich hinzugeholt wurde, basieren noch auf Java 8, die moderneren hingegen schon auf Java 14. Von den modernen Entwicklungen im Java-Umfeld bin ich weit entfernt, und auch andere Programmierer geben mir das Feedback, dass sie dasselbe Problem haben. Trotzdem informiert man sich jedes Mal wieder, wenn eine neue Java-Version auftaucht, liest sich Blogs durch, schreibt ein paar lustige Programmzeilen, nur so für sich und dann vergisst man es wieder bis zur nächsten Java-Version.
Java 8 wurde 2014 veröffentlicht, jetzt 10 Jahre später wird es immer noch in vielen Projekten angewendet. Und das muss sich auch nicht ändern. Java 8 wird noch bis 2030 unterstützt. Erst danach müsste man auf eine modernere LTS-Version überwechseln.
Es ist verständlich, das Firmen bzw. Projektleiter auf eine LTS-Version vertrauen und nicht jedes Jahr einen neue Java-Version einspielen wollen, aber neben Java 8, sind auch Java 11, Java 17 und Java 21 LTS-Versionen.
Bei der Umstellung auf modernere Java-Versionen gibt es meiner Meinung nach verschiedene Dinge, die die Umstellung behindern.
Das Projekt
Die Umstellung auf eine neue Java-Version ist immer mit Kosten verbunden, schließlich muss ein Team sich darum kümmern und das ganze Projekt muss ausgiebig getestet werden. Das ist bei den meisten Projekten, wo man ja sowieso schon hinter dem Zeitplan hinterherhinkt ein zusätzliches Problem, das man schlecht den Projektverantwortlichen erklären kann. Nur falls die aktuelle LTS-Version nicht mehr unterstützt wird, muss aus Sicherheitsgründen eine Umstellung erfolgen, was auch die Projektverantwortlichen einsehen.
Dann allerdings ist der Aufwand viel größer, da sich noch mehr geändert hat. Das Testen nimmt noch mehr Zeit in Anspruch, so dass die Projektverantwortlichen diese Erfahrung mit ins nächste Projekt nehmen und auch dort konservativ auf der aktuellen LTS-Version beharren.
Tatsächlich ist ein jährliches Übergehen auf die nächste Java-Version durchaus sinnvoll und weniger fehleranfällig. Und es spricht ja auch nichts dagegen, 3 oder 5 Java-Versionen zurück zu sein.
Ein weiteres Problem sind die Abhängigkeiten zu anderen Tools, Programmen und Libraries im Java-Kontext. Die Erhöhung auf eine neuere Java-Version zieht oft auch die Aktualisierung von anderer Software nach sich. Nicht immer gibt es eine neuere Version. Häufig arbeiten Firmen noch mit Software, die längst aufgegeben wurde, und von der es keine neuere Version gibt, oder eben nur eine Preview-Version von einer Community, die diese Software weiterpflegt. Zudem ist es aus Sicherheitsgründen oft nicht möglich solche Software zu verwenden, so dass sich nach einer Alternativ-Software umgesehen werden muss. Das verzögert die Umstellung auf eine neue Java-Version zusätzlich.
Um so abhängiger von Fremd-Software das Projekt aufgebaut wurde, um so schwerer ist eine Umstellung.
Interessanterweise gibt es aber auch den umgekehrten Effekt. Ich möchte z. B. eine neuere Version meiner Hilfs-Software verwenden und diese beharrt auf eine neuere Java-Version. In diesen Fällen geht die Umstellung meistens schneller. Oft sind es neue oder externe Mitarbeiter, die sich wundern, warum man noch mit einer bestimmten Fremd-Software arbeitet. Sie empfehlen ein anderes Produkt, weil es viele Vorteile bringt. Um diese Software nutzen zu können, muss auch andere Software aktualisiert werden, so dass schließlich auch Java auf eine neue Version gehoben wird.
Das Problem liegt allerdings auch in Java selbst begründet, denn es kommen nicht nur neue Dinge dazu, sondern es fallen auch ständig Dinge weg. Das führt zu vermehrter Anpassungsarbeit. Natürlich gibt es erst mal „Deprecated“-Warnungen über viele Java-Versionen hinweg. Das ist aber nur dann eine eine nützliche Information, wenn das Projekt von einer Java-Version zu nächsten migriert. Wenn aber Jahre lang nichts getan wird und dann plötzlich zu einer höheren Java-Version gewechselt wird, dann gibt es eben etliche Dinge, die angepasst werden müssen.
Klarerweise setzt das ebenso voraus, dass das Projekt generell mit Warnungen proaktiv umgeht. Sollten „Deprecated“-Warnungen ignoriert werden, dann müssen diese ganzen Änderungen zu einem Zeitpunkt alle auf einmal umgesetzt werden. Und so ist sicherlich auch die schlechte Umsetzung von Clean Code in vielen Projekten ein Grund für das Hinterherhinken.
Hier sollten eigentlich Tools wie Sonar helfen. In der Praxis habe ich aber oft erlebt, dass viele Warnungen nicht dazu führen, das Sonar ernster genommen wird, sondern dass genau das Gegenteil eintritt und Warnungen ignoriert werden.
Wenn man also regelmäßig die Java-Versionen hochzieht, dann muss man sich auch dazu verpflichten, die jedes Mal neu hinzukommenden Warnungen abzuarbeiten. Ein Committent, daß man den Entwicklern abverlangen muss.
Die Entwickler
Bei den Entwicklern gibt es zwei Typen von Entwicklern. (Natürlich gibt es noch viel mehr, aber für unseren Gedanken brauchen wir nur diese beiden.)
Interessiert an neuer Technologie, bereit Risiken einzugehen
Interessiert an einem laufenden System, konservative Herangehensweise
Nun ist es natürlicherweise so, dass der erste Typus oft die Firma wechselt und sich auch fürs Projektgeschäft interessiert, damit er immer neue Dinge lernen und verbessern kann. Dadurch wird es für diesen Entwickler nicht langweilig.
Der zweite Typus bleibt meistens länger in einer Firma und erfreut sich mit dem wachsenden Erfolg der Firma an der stabilen Umgebung. Dieser Entwickler zieht seine Befriedigung aus dem fehlerfreien Ablauf der Software.
Diese Unterteilung gibt es selbstverständlich auch bei Führungskräften und Product-Ownern. Wenn eine Firma also über längere Zeit existiert, kristallisiert sich eine eher konservative Belegschaft heraus, weswegen es Neuerungen bei vielen Firmen sehr schwer haben. Nur wenn die Firma eine progressive Einstellung hat, die Mitarbeiter zur Fortbildung ermuntert und eine tolerante Fehlerkultur existiert, können über einen langen Zeitraum Strukturen geschaffen werden, in denen neue Software ausprobiert wird. Und das gilt dann natürlich auch für Java.
Fazit: Alles bleibt, wie es ist
Wenn man das so betrachtet, wird sich wohl erst einmal nichts ändern. Wir müssen damit leben, dass wir mit veraltetem Java arbeiten. Nur in kleinen Projekten und progressiven Firmen könnte man wohl mal in den Genuss des neuen Javas kommen.
