Das Entwicklernähkästchen 2019/2020 – Teil 4

Ein Blick zurück: Die größten Enttäuschungen im Java-Universum 2019

Dominik Mohilo

© Shutterstock / Tero Vesalainen

Da sich das Jahr 2019 dem Ende zuneigt, haben wir mit einigen prominenten Mitgliedern der Java Community Kontakt aufgenommen, um ihre Gedanken zu den Ereignissen des letzten Jahres zu sammeln. In dieser fünfteiligen Serie werden wir uns ansehen, was sie zu sagen haben. Im vierten Teil geht es um die größten Enttäuschungen des vergangenen Jahres.

Die Einigungen zwischen Oracle und der Eclipse Foundation bezüglich Java EE. Die Tatsache, dass Jakarta EE den javax-Namespace nicht benutzen darf und daher in der nächsten Version Breaking Changes einführen muss, ist ein großer Rückschlag. Auf der anderen Seite ist es hier beeindruckend zu sehen, wie die Community mit diesen Tatsachen umgeht und sich auf ein gemeinsames Vorgehen dazu einigt.

>> Tim Zöller – Team Leader Java bei der ilum:e informatik AG

Da fällt mir nur die Entscheidung Oracles ein, die Lizenz für Oracle Java SE anzupassen.

>> Thomas Darimont – Gründer der Java User Group Saarland und Fellow bei der codecentric AG

Ganz klar: Jakarta EE / JPA. Ich hatte große Hoffnung in Jakarta EE gesetzt, insbesondere weil das Spring-Data-Team wohl eins der wenigen ist, die tatsächlich JPA nutzen, um unterschiedliche Implementierungen anzubinden. Da findet man natürlich ab und an mal einen Fehler in einer Implementierung, oder einfach Lücken in der Spezifikation. Ich hatte von einer Welt geträumt, in der ich dann ein Issue mit zwei Pull Requests anlegen kann. Nach dem Motto: Es existieren folgende Interpretationen der Spezifikation, entscheidet euch für eine der beiden Varianten, indem ihr einen der beiden PRs merged, der dann das Verhalten festschreibt und im TCK abtestet. Aber gefühlt ist da null Bewegung drin. Die TCKs sind nach wie vor in einem Zustand, der das Ausführen unverhältnismäßig aufwändig macht.

>> Jens Schauder – Spring Data Team bei Pivotal

Ich fühle, dass es ein bisschen zu viel Aufmerksamkeit für Java(FX)-Distributionen gibt, und nicht genug für Java(FX)-Commits. Alle Java-Projekte hängen letztlich von der Qualität von OpenJDK ab. Alle JavaFX-Projekte hängen von der Qualität von OpenJFX ab. Es ist extrem wichtig, dass es genügend finanzielle Mittel für OpenJDK/OpenJFX gibt.

>> Johan Vos – Java Champion und Mitgründer von Gluon und LodgON

Ich würde nicht sagen, dass ich enttäuscht bin. Aber trotz vieler Java-Veröffentlichungen in den letzten Jahren habe ich festgestellt, dass die Mehrheit der Projekte immer noch Java 8 verwendet. Daher würde ich es begrüßen, wenn immer mehr Projekte zumindest auf Java 11 migrieren würden, damit sie die Vorteile der neuen Java-API-Erweiterungen sowie der neuen JVM GCs (Garbage Collectors), wie G1 oder ZGC, nutzen können.

>> Vlad Mihalcea – Java Champion und Autor des Buches „High-Performance Java Persistence“

Nichts im Speziellen. Es gibt immer die Pessimisten, die sagen, Java stirbt oder die Sprachen/Organisationen/Ansätzen gegenüber ultra-kritisch sind. Das ändert sich nicht, vielleicht ist das die größte Enttäuschung.

>> Trisha Gee – Java Champion und Developer Advocate bei JetBrains

Nichts so richtig. Ich schätze, wenn ich etwas sagen müsste, wäre das die Umbennenung der JavaOne in CodeOne, aber ich verstehe natürlich, dass sie den Fokus für eine breitere Audience anpassen wollten.

>> Simon Ritter – Java Champion und Deputy CTO bei Azul Systems
 
 

Die ständigen Vergleiche von Frameworks im luftleeren Raum. Technik ist dazu da, fachliche Probleme zu lösen. Ein Vergleich verschiedener Dinge ist demnach nur im Kontext eines konkreten Problems sinnvoll. Das Framework X schneller startet als Y, wobei in beiden nur ein Controller mit statischem Rückgabewert implementiert wurde, hilft mir dabei wenig. Ich verstehe, dass heute jede Technologie auch „Werbung“ für sich machen muss, um sich von der „Konkurrenz“ abzuheben, aber ich würde mir gerade bei Vergleichen wünschen, dass sich diese mehr an wirklich konkreten Problemen orientieren.

>> Michael Vitz – Senior Consultant bei der innoQ Deutschland GmbH

Hier musste ich wirklich länger nachdenken, habe dann aber doch etwas gefunden: Auch wenn beginnend mit JavaFX 11 das UI Toolkit aktiv weiterentwickelt wird und sogar LTS-Versionen angeboten werden, sieht es mit JavaFX 8 ganz anders aus. Zwar bieten einige Firmen JavaFX als Bestandteil ihrer Java-8-LTS-Versionen an, die Qualität bzgl. Bugfixes ist hier leider oft nicht so gut. Schade ist auch, dass hier niemand Fixes in das OpenJDK Repository contributed. Alle Firmen scheinen hier auf einem privaten Fork zu arbeiten. Somit ist es für AdoptOpenJDK z.B. nicht möglich, JavaFX für Java 8 anzubieten, da die Open Source verfügbare Version nicht weiter gepflegt wird.

>> Hendrik Ebbers – Java Champion und Java-Entwickler bei der Karakun AG

Auch wenn alle Hersteller und die technischen Gremien mitgemacht haben, so hatte es einige Zeit gebraucht, bis die Eclipse Foundation mit Jakarta EE an den Start gehen konnte und sich mit der Weiterentwicklung beschäftigen konnte. Aber zerstörte Hoffnung im Java-Universum konnte ich nicht feststellen. Im Gegenteil, meine Anerkennung gebührt denjenigen, die sich bei der Neugestaltung von Jakarta EE beteiligen.

>> Wolfgang Weigend – Sen. Leitender Systemberater bei der Oracle Deutschland B.V. & Co. KG

Auch wenn der Meilenstein Jakarta EE 8 wichtig war, so ist natürlich das aktuelle Tempo eher enttäuschend. Insbesondere weil wir vermutlich im nächsten Jahr mit Jakarta EE 9 wieder nur ein Maintenance Release bekommen, in dem die Package-Namen java/javax durch jakarta ersetzt werden.

>> Falk Sippach – Trainer, Software-Entwickler und -Architekt bei der OIO

Geschrieben von
Dominik Mohilo
Dominik Mohilo
Dominik Mohilo studierte Germanistik und Soziologie an der Goethe-Universität in Frankfurt. Seit 2015 ist er Redakteur bei S&S-Media.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: