Die Diskussionen um die Stagnation bei Java EE gehen weiter. Wir reden heute mit Sebastian Daschner, Mitglied der Experten-Gruppe für JAX-RS und einer der Java EE Guardians, über seine Interpretation des Zustands der Java Enterprise Edition.

Bevor wir mit dem Interview beginnen, ein kleines Update: Kürzlich wurden Protokolle des JCP Exekutiv-Komitees öffentlich gemacht, in denen sich u.a. ein offizielles Statement der Mitglieder an Oracle befindet. Das Komitee bringt darin seine Hoffnung zum Ausdruck, dass Oracle Community-Vertretern die Weiterentwicklung der EE-Plattform in Bereichen gestattet, in denen es sich zurückzuziehen gedenkt:

„EC members expressed their serious concerns about the lack of progress on Java EE. They believe that Java EE is critical to the Java ecosystem and to their organizations and customers. They fully accept Oracle’s right to direct its investment where it wishes, but expressed the hope that they and other members of the Java community be permitted to step in and help with the ongoing development of the platform, particularly in areas where Oracle wishes to reduce its investment. They therefore requested a dialog with Oracle about how to make such a transition.“

Es bleibt also spannend! Unterdessen geht es weiter in unserer Interview-Serie: Heute gibt Sebastian Daschner seinen Standpunkt wieder.

„Inaktive JSRs sollten von den Spec-Leads freiwillig an andere übergeben werden“

JAXenter: Hallo Sebastian. Du unterstützt verschiedene Java EE JSRs wie JAX-RS und JSONB und bist Autor des Open-Source-Tools JAX-RS Analyzer – außerdem wurdest du vor wenigen Tagen in den Kreis der Java Champions aufgenommen. Ein aktives Mitglied der Java EE Community würde ich also sagen. Bevor wir zur Situation um Java EE 8 kommen, möchte ich den Blick auf die aktuelle Plattform-Version lenken. Wie würdest du den Zustand von Java EE 7 beschreiben?

Es ist erstaunlich, wie viel Boilerplate-Code sich entfernen lässt, wenn man auf die neueste EE-Version migriert.

Sebastian Daschner: Schon seit Java EE 6 und erst recht seit EE 7 lassen sich mit diesem Framework sehr produktiv und effektiv Enterprise-Anwendungen entwickeln. Für die allermeisten Use-Cases reicht ein Plain-EE-7-Ansatz ohne externe Dependencies aus. Das spiegelt sich sehr oft auch in meinen Kundenprojekten wider: Es ist erstaunlich, wie viel Boilerplate-Code und wie viele Third-party Dependencies sich entfernen lassen, wenn man auf die neueste EE-Version migriert, bzw. diese sinnvoll einsetzt.

JAXenter: Wo siehst du noch Bedarf für Verbesserungen? Wie sollte sich Java EE technologisch weiterentwickeln?

Sebastian Daschner: Einer der größten Vorteile von EE ist meiner Meinung nach die sehr gute Integration und Wiederverwendbarkeit diverser Spezifikationen. Wenn man in EE 6 und 7 entwickelt, fühlt sich alles wie „aus einem Guss“ an – hauptverantwortlich dafür ist CDI. Das ist ein Vorteil, den ich in EE 8 noch weiter ausgebaut haben möchte – siehe dazu auch folgende Blogeinträge über JSONB und über Java EE allgemein.

JAXenter: Dann kommen wir jetzt zu Java EE 8. Was ist deine Sichtweise der aktuellen Situation um Java EE 8? 

Sebastian Daschner: Bis letzten Jahres ca. im Oktober sah es mit dem Entwicklungsstand recht gut aus. Seitdem sind jedoch einige JSRs faktisch zum Stillstand gekommen, was in den Fällen vor allem daran liegt, dass die jeweiligen Spec-Leads wenig bis gar nicht auf Feedback, Vorschläge oder Pull Requests eingehen. Damit wird leider auch der Gesamtfortschritt von EE 8 verzögert, was für die EE-Community durchaus ein Problem darstellt.

JAXenter: Die „Java EE Guardians“ haben sich nun zum Ziel gesetzt, dieses Problem anzugehen. Wie könnte das geschehen?


Sebastian Daschner: Einige sinnvolle Aktivitäten – die so schon passieren – sind die Implementierungen und damit letztendlich auch die Spezifikationen voranzutreiben. Viel passiert z. B. schon mit JCache oder MVC. Bei den Spezifikationen sind die größten Hindernisse die JSRs, die seit Monaten keinen wirklichen Fortschritt aufweisen. Ich bin mir sicher, dass die „Guardians“, sowie genug andere Firmen bzw. Entwickler aus der Java-Community, in solchen Fällen gerne sofort übernehmen würden. Sinnvoll wäre es einfach, wenn die entsprechenden JSRs von den Spec-Leads freiwillig an andere übergeben würden. Hier versuchen die „Guardians“, auf diese Fälle aufmerksam zu machen, um vor allem aus der Java-Community bzw. vom JCP Unterstützung zu bekommen.

JAXenter: Auch du hast dich den Java EE Guardians angeschlossen. Warum? 


Ich muss die „Unresponsiveness“ Oracles leider zu oft selbst feststellen.

Sebastian Daschner: Ich bin sehr stark am Voranschreiten von Java EE interessiert – persönlich wie auch für meine Kundenprojekte. Standardisierte Enterprise-APIs zu haben, ist an vielen Stellen von unschätzbarem Vorteil. Und natürlich geht es mir nicht zuletzt auch darum, am Fortschritt selber mitwirken zu können.

Wenn jedoch durch andere Prioritäten von Unternehmen wie Oracle der Fortschritt (unfreiwillig) aufgehalten wird, verzögert das nur unnötig neue Versionen. Ich bin in der JAX-RS 2.1 Expert Group vertreten und muss diese Verzögerungen und die „Unresponsiveness“ leider zu oft selbst feststellen. Daher bin ich bereit, bei dem Problem zu unterstützen.

JAXenter: Könnte Java EE aus deiner Sicht gänzlich von der Community – oder gar ohne JCP – entwickelt werden?  


Sebastian Daschner: Außerhalb des JCP nicht, das ist ja genau der Vorteil, den Java und EE gegenüber anderen Technologien und Frameworks haben. Die Vorgehen sind festgelegt, jeder kann sich beteiligen, und es existieren Komitees, die sicherstellen, dass das Gesamtbild der Technologie zusammenpasst. Der JCP trägt das Wort „Community“ ja schon im Namen.

Ein Java EE ohne (zwangsläufige) Beteiligung von Oracle oder anderen Unternehmen kann ich mir durchaus vorstellen – es existieren genug andere Player, die ein großes Interesse an EE haben. Ob die Beteiligung von Oracle ein Vorteil oder Nachteil ist, finde ich, lässt sich fairerweise so pauschal nicht beurteilen. Unbedingt nötig ist eine Beteiligung nicht. Zum Problem wird es erst, wenn durch unglückliche Situationen der Gesamtfortschritt verzögert wird.

JAXenter: Vielen Dank für dieses Interview!

Sebastian Daschner arbeitet als freiberuflicher Java Consultant, Softwareentwickler bzw. -architekt und programmiert begeistert mit Java (EE). Er nimmt am Java Community Process teil, ist in der JSR 370 Expert Group vertreten und entwickelt an diversen Open-Source-Projekten auf GitHub. Er ist ein Java Champion und arbeitet seit über 6 Jahren mit Java. Darüber hinaus benutzt Sebastian auch intensiv Linux und Containertechnologien wie Docker. Er evangelisiert Java- und Programmierthemen unter https://blog.sebastian-daschner.com und auf Twitter unter @DaschnerS