E-Book „Java-Tools und -Frameworks“ Java-Trends 2022
Für die Java-Community brachte das vergangene Jahr eine große Überraschung nach der anderen. Auf einmal schien sogar Oracle aus dem Winterschlaf aufzuwachen. Der Ausblick bringt auch einen deutlichen Hoffnungsschimmer.

Oracle hatte sich eine Zeitlang auf seinen Lorbeeren gemütlich gemacht und damit eine Menge Entwickler verärgert. Vor allem die Lizenzkosten sind vielen kleineren und mittelgroßen Entwicklerschmieden sauer aufgestoßen.
Im Frühling 2021 musste Oracle im größten Gerichtsstreit der IT-Geschichte gegen Google um die Java-APIs in Android nach einem Jahrzehnt von Auseinandersetzungen eine Schlappe einstecken. Das Oberste Gerichtshof der Vereinigten Staaten hat am 5. April Klarheit geschaffen (man hat zur Sicherheit vier Tage abgewartet, damit es keine Zweifel gibt). Java-APIs sind unter der Fair-Use-Doktrin doch frei nutzbar.
Oracle kann Entwickler nicht mehr daran hindern, Java-APIs zu verwenden, um neue – auch rein kommerzielle – Anwendungen zu coden. Noch war die Tinte auf dem Urteil feucht, da hat Oracles alte Nemesis Microsoft eine eigene Java-Variante veröffentlicht: einen eigenen Build von OpenJDK mit Binaries für Java 11. Einen ganzen Tag nach der Urteilsverkündung ließ man sich damit in Redmond Zeit.
In Oracles neuer Zentrale in Austin im US-Bundesstaat Texas läuteten anscheinend die Alarmglocken. (Oder war es ein Wecker?) Und siehe da: Seit September 2021 ist Oracles JDK für Java 17 und nachfolgende Versionen unter einer freien Lizenz verfügbar. Oracles Support in der Ausbaustufe Premier für Java SE 17 (LTS) soll erst September 2026 und in der Variante Extended sogar im September 2029 auslaufen.
Java aus Redmond
Microsofts Code-Hosting-Service GitHub will der Ort sein, „where the world builds software“. Unter seinen 73 Millionen Entwicklern und 200 Millionen Repos kann der Dienst auf eine ansehnliche Anzahl hochkarätiger Java-Projekte verweisen (Redmond hatte mit dem Kauf von GitHub für 7,5 Milliarden USD echt ein Schnäppchen geschlagen). Scharen talentierter Java-Entwickler haben GitHub ihren wertvollen Code anvertraut. Java fühlt sich bei Microsoft schon länger zuhause. Das hat ganz banale Gründe: Java lässt die Kasse klingeln.
In Microsofts Visual Studio Code könnten Entwickler ihren Java-Code kompilieren und debuggen (wenn sie wollten – die einen wollen, die anderen nicht). Die Java-Gemeinde arbeitet stattdessen lieber in IntelliJ IDEA, Eclipse und NetBeans. Doch ungeachtet der Entwicklungsumgebung kassiert Microsoft (mit) ab: an der kostenpflichtigen Ausführung von unternehmenskritischen Java-Arbeitslasten auf Azure.
Microsofts Public Cloud rangiert als die Nummer Zwei im Gartners Magic Quadrant für Cloud Infrastructure as a Service; Oracle steht weit abgeschlagen im Kästchen „unter ferner liefen“ (a.k. Nischenanbieter). Die Beharrlichkeit, mit der Microsoft in Java und Azure investiert, würde Oracle selbst gut zu Gesicht stehen.
Anfang November hat Microsoft neue Java-Tools für Azure Kubernetes Service (AKS) veröffentlicht. Damit lassen sich Java Enterprise Edition-Anwendungen (Java EE) und die Kubernetes-basierte OpenShift-Plattform von IBMs Tochter Red Hat auf Azure ausführen. Rund zwei Tage später hat Red Hat die erste Version seiner Sprachunterstützung von Java für Visual Studio Code mit Unterstützung für Maven, Gradle und Java-Standalone bereitgestellt.
Microsoft hat ja auch in Sachen Linux längst keine Berührungsängste mehr, warum soll man da welche bei Java haben. Microsofts Linux-Supercomputer Voyager-EUS2 hat es Mitte November in der TOP500-Supercomputer-Liste auf Platz 10 geschafft. Zwischen 51 und 60 Prozent der Azure-Arbeitslasten laufen ebenfalls auf Linux, ob von Red Hat, Oracle oder jemand anderem.
Was Java-Entwicklern den Schlaf raubt
Die Notwendigkeit, die Cybersicherheit unternehmenskritischer Arbeitslasten zu gewährleisten, ohne die Leistung oder Skalierbarkeit aufs Spiel zu setzen, zählt zu den wichtigsten Argumenten für den Einsatz von Java und eine der treibenden Kräfte für die Weiterentwicklung der Sprache. Das Ende von öffentlichen Java-SE-8-Updates hat keinen Entwickler wirklich überrascht.
Den einen oder anderen Java-Entwickler hat hingegen die Umstellung von OpenSSL 1.1.1 auf OpenSSL 3.0 kalt erwischt, weil es die Kompatibilität vieler wichtiger Libraries bricht. In der Java-Gemeinde zirkulieren inzwischen Gerüchte um eine potenzielle Änderung des Veröffentlichungsrhythmus von LTS-Releases von drei auf alle zwei Jahre. Alle großen Anbieter von OpenJDK sollen mit an Bord sein.
Dafür gibt es ja auch gute Gründe. Java fehlt aktuell ein „Killer-Feature“, welches aus Sicht der Entwickler den Aufwand einer massiven Umstellung der bestehenden Code-Basis auf die aktuelle Version des SDK rechtfertigen würde. Projekt Valhalla und die Aufnahme von Werttypen in die Sprache könnten in Zukunft einen solchen Wendepunkt darstellen.
Aber selbst, wenn man die schnellere LTS-Release-Kadenz berücksichtigt, rechnen Insider nicht unmittelbar damit, dass Werttypen in eine LTS-Version Einzug halten. Kürzere Release-Zyklen könnten ein höheres Innovationstempo ermöglichen, sofern die Entwickler damit Schritt halten wollen. Das wird sich erst noch erweisen müssen.
Fazit
Java EE ging es eigentlich noch nie so gut. Für Java-Entwickler stehen die Zeichen auf Wachstum. So unwahrscheinlich das klingen mag, Java ist jetzt sogar bei Microsoft hoffähig.
Oracle sieht sich anscheinend genötigt, das Ruder des Java-Ökosystems wieder an sich zu reißen. Eine Kurskorrektur war ja längst überfällig. Mal schauen, wo es jetzt lang geht. Das eBook „Java-Tools und -Frameworks“ bringt Licht in die aktuellen Umwälzungen der Java-Landschaft.
(ID:48132434)