Suche
Interview mit Sven Kölpin

Zeitgemäße Webentwicklung: Java EE oder JavaScript?

Hartmut Schlosser

Sven Kölpin

Java EE 8 wird noch in diesem Jahr erscheinen – doch ist die neue Version der Java Enterprise Edition wirklich die Antwort auf die Herausforderungen moderner Webentwicklung? Wir haben mit Sven Kölpin über das neue Release gesprochen. Außerdem klären wir, ob der Ansatz „Universal JavaScript“ eine tragfähige Alternative darstellt, und wie die Marschroute in Richtung Java EE 9 aussehen könnte.

JAXenter: Hallo Sven! Web-Apps on Steroids heißt Euer Workshop auf dem Java Enterprise Summit. Vorbei sind die Zeiten altbackener Webanwendungen. Was gehört deiner Auffassung nach in eine moderne Webanwendung, was gehört noch zur alten Welt?

Aus architektonischer Sicht ist heutzutage alles das modern, was in Richtung von Single-Page-Anwendungen geht.

Sven Kölpin: Moderne Webanwendungen können verschiedene Ausprägungen haben. Aus architektonischer Sicht ist heutzutage alles das modern, was in Richtung von Single-Page-Anwendungen geht. Dazu gehört ein möglichst zustandsloses Backend mit einer JSON-basierten API-Schnittstelle und ein auf JavaScript basierendes Frontend, das clientseitig gerendert wird.

Dieser Ansatz hat zwei wesentliche Vorteile gegenüber serverseitig rendernden Webanwendungen. Erstens skalieren Single-Page-Anwendungen in der Regel besser. Der Server kann ausschließlich als Datenlieferant agieren und muss sich nicht um die Verwaltung von Sessions oder um das Rendern der Benutzeroberfläche kümmern. Zweitens müssen im Vergleich zu klassischen Webanwendungen weniger Anfragen über das Netzwerk versendet werden, weil ein Großteil der UI-Logik und der Daten in den Browser verlagert sind.

Der Single-Page-Ansatz ist aber natürlich keine Lösung für jedes Problem. Es gibt viele Anwendungsfälle, in denen eine klassische, serverseitig rendernde Architektur sinnvoller ist. Selbstverständlich können auch solche Anwendungen auf eine „moderne“ Art umgesetzt werden. Für mich ist dazu der intensive Einsatz von JavaScript, auch wenn es nur für die DOM-Manipulation verwendet wird, sowie die Nutzung aktueller Browser-APIs (z.B. localStorage oder ServiceWorker) unabdingbar.

JAXenter: Ketzerisch könnte man fragen, warum denn überhaupt noch Java für Web-Apps nutzen? Geht das in Zeiten von Node.js, React und Angular nicht auch alles mit JavaScript?

Sven Kölpin: Der Hype, Node.js als serverseitige Alternative zu Java zu verwenden, ist keineswegs unberechtigt. Die Event-driven und Non-blocking I/O Architektur ermöglicht die Erstellung ressourcensparender und skalierbarer Anwendungen. Dazu kommt, dass während der Entwicklung nur noch eine Programmiersprache für Front- und Backend verwendet wird. Das ist ein nicht zu unterschätzender Vorteil (Stichwort: Universal JavaScript). Nicht ohne Grund ist Node.js deshalb ein fester Bestandteil in den Systemarchitekturen von Netflix, Paypal & Co.

Lesen Sie auch: Reaktive Programmierung: Java EE, Spring 5 oder NodeJS?

Trotzdem gibt es natürlich Bereiche, in denen sich Java-Anwendungen besser eignen. So ist Node.js beispielsweise Single-Threaded – für Anwendungen mit CPU-intensiven Berechnungen ist Java also die bessere Wahl. Unabhängig von architektonischen Dingen spielen natürlich auch die Programmiersprache als solche, sowie die Enterprise-Fähigkeit eines Frameworks eine nicht unwesentliche Rolle. Auch hier hat Java als typsichere Sprache und dem Java-EE-Standard im Rücken wesentliche Vorteile. Zusätzlich gibt es auch in der Java-Welt Umsetzungen der Event-driven und Non-blocking-Architektur.

Java-Backends werden auch in den nächsten Jahren noch zuverlässige Datenlieferanten für JavaScript-Frontends bleiben.

Es ist also niemand gezwungen, auf Node.js zu wechseln, und Java-Backends werden auch in den nächsten Jahren noch zuverlässige Datenlieferanten für JavaScript-Frontends bleiben. Trotzdem solle man Node.js keineswegs ignorieren.

JAXenter: Wenn wir uns hier den aktuellen Java-EE-Standard ansehen – welche Teile davon sind aus deiner Sicht nicht mehr so ganz zeitgemäß, welche weisen in die Zukunft? 

Sven Kölpin: Java EE ist eine sehr umfangreiche Spezifikation, in der es aus historischen Gründen viele APIs gibt, deren Verwendung aus heutiger Sicht nicht mehr ganz zeitgemäß ist. Das ist aber gut so, denn im Enterprise-Umfeld hat man nicht immer nur mit den neusten Technologien zu tun. Vielmehr müssen technologische und architektonische Entscheidungen, die in der Vergangenheit noch als „Best Practices“ galten, viele Jahre weiter unterstützt werden.

Lesen Sie auch: Java EE 8 – das sind die Highlights

Die wichtigste Spezifikation ist und bleibt für mich CDI, weil diese stets die Grundlage für bestehende und zukünftige APIs bildet. Im Zeitalter von Single-Page- und Microservice-Architekturen gewinnt zudem die JAX-RS-Spezifikation stetig an Bedeutung. Gleichzeitig beobachte ich, dass das Interesse an JSF immer weniger zu werden scheint – nicht zuletzt aufgrund des verheerenden Urteils im Technologie-Radar des Jahres 2015.

JAXenter: Bald steht ja das Java EE 8 Release an. Was ist an dem Release für dich spannend?

Für die Zukunft von Java EE wünsche ich mir vor allem kürzere Release-Zyklen und weniger politisches Hin und Her.

Sven Kölpin: Das Java EE 8 Release steht, wie schon Java EE 7, ganz im Zeichen moderner Webanwendungen und Web-APIs. Für mich ist es wichtig zu sehen, dass viele Features, die sich in den letzten Jahren bereits durch Bibliotheken von Drittanbietern etabliert haben, ihren Weg in den Standard finden. Konkret sind hier JSON-B, die Erweiterung von JSON-P sowie einige Features in JSF 2.3 zu nennen.

Spannend ist außerdem die neue Servlet-Spezifikation, mit der beispielsweise HTTP/2 Push implementiert werden kann. Das ist ein wichtiges Feature für die Umsetzung zukunftssicherer Webapplikationen. Auch die Unterstützung von Server-sent-Events (SSE) in der aktualisierten JAX-RS-Spezifikation ist für mich ein wichtiger Schritt, um die EE-Plattform modern zu halten.

JAXenter: Welche Umsetzungen wünscht du dir für Java EE 9? 

Sven Kölpin: Für die Zukunft von Java EE wünsche ich mir vor allem kürzere Release-Zyklen und weniger politisches Hin und Her. Um wettbewerbsfähig zu bleiben, müssen technologische und architektonische Veränderungen viel schneller in den Standard integriert werden können. Für Java EE 9 würde ich mir einen stärken Fokus auf Event-driven und Non-Blocking I/O-Architekturen wünschen. Die Themen Cloud und Microservices bleiben natürlich auch spannend.

JAXenter: Vielen Dank für dieses Interview!

Sven Kölpin ist Enterprise-Entwickler, Speaker und Autor bei der open knowledge GmbH in Oldenburg. Schwerpunkt und Leidenschaft ist die Konzeption und Entwicklung von Web-Anwendungen.

X

Mehr zum Thema:

Ausführlich über die Neuerungen in Java EE 8 können Sie sich im aktuellen Java Magazin informieren:

Infos unter: www.javamagazin.de

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare
  1. KMUS2017-08-04 13:26:16

    Daß das Interesse an JSF 2.2.x und jetzt 2.3 stetig abnimmt(obwohl ich erst neulich gegenteiliges gelesen habe), zeigt die große Unwissenheit über diese Technologie . Mit JSF und Primefaces lassen sich sehr moderne Web-Applikationen entwickeln, die nicht nur hübsch und schnell sind, sondern auf ein Industriestandard setzen, den es noch in fünf bis zehn Jahren oder länger geben wird.

    REST-Architekturen stellen eine großer Herausforderung dar und sollten nur dann eingesetzt werden, wenn wirklich eine Notwendigkeit besteht. Wer hier auf den Medien-Hype reinfällt, kann es schon wenig später bitter bereuen. Denn so einfach wie im obigen Text geschrieben, ist es leider doch nicht. Z.B. Horizontale Skalierung, eventuell noch mit Abhängigkeiten, die über große Entfernungen kommunizieren müssen, sind kein Pappenstiel und wenn schon REST, dann mit Jersey, Weld und Hibernate und keinem Backend, was auf einer CPU nur läuft. Das war gestern.

    Isomorphic programming, vom Client bis zum Server alles z.B. in Javascript, ist auch so ein typisches Schlagwort in den Medien, was mit der Realität bis auf Ausnahmen kaum zu tun hat. Dort zeigt die Erfahrung, Mehrsprachigkeit und Multiparadigmensprachen sind das A und O. Müßte ich meine Probleme backend-seitig ausschließlich mit Javascript lösen, hätte ich schon längst das Handtuch geworfen. JS ist gerade erst dabei, sich zu einer ernsthaften Sprache(TypeScript bedingt) zu entwickeln, mit der sich dann hoffentlich größere Projekte realisieren lassen. Der Beweis ob dies über einen längeren Zeitraum auch gelingt, steht noch aus. Bei Java haben wir Gewissheit.

    Es ist zwar richtig, daß Netflix Javascript und Node.js einsetzt, dies aber nur um den Seitenaufbau flüssiger zu gestalten. Backend-seitig laufen dort sehr viele Systeme mit Java und anderen Technologien. Ebenfalls bei Twitter. Facebook setzt serverseitig sogar auf PHP. Wie man sieht, keine Monokulturen. Dort wird Javascript nur dann eingesetzt, wenn es technologisch Vorteile bringt.

    Wer ausschließlich Javascript, Node.js und NoSQL als Zukunftslösungen propagiert, hat entweder keine Ahnung oder ist Nutznießer jener Technologien.

  2. Sven Kölpin2017-08-08 10:35:22

    Zu 1.)
    Wie im Interview zu lesen, bin ich da vollkommen einverstanden. Eine Single-Page-Architektur ist nur in bestimmten Fällen sinnvoll. Vor allem bei stark formularbasierten Webanwendungen eignen sich klassische, serverseitig rendernde Frameworks (wie z.B. JSF mit Primefaces) oftmals besser – und es lassen sich, wie im Interview beschrieben, auch mit JSF durch den Einsatz von JavaScript moderne Webanwendungen entwickeln (Primefaces macht das natürlich unter der Haube für uns ).
    Meine Beobachtung, dass das Interesse an JSF stetig abnimmt basiert auf der stark veränderten Lage der Projekt- und Schulungsanfragen.

    Zu 2.)
    Vollkommen richtig, wobei ich hier bewusst zwischen REST-Architekturen und JSON- bzw. HTTP-basierten Schnittstellen unterscheide – denn für Single-Page-Anwendungen sind „echte“ REST-Schnittstellen aus dem Lehrbuch (vgl. Fielding, 2000) oftmals unvorteilhaft. Mit welchen Frameworks diese Schnittstellen umgesetzt werden, ist natürlich erstmal egal. Wichtig ist zu verstehen, dass bei SPAs grundsätzlich keine Templating-Engine bzw. kein schwergewichtiges, serverseitiges Komponentenframework mehr benötigt wird und das entlastet einen Server nicht unerheblich.

    Zu 3.)
    Ich habe damit sehr gute Erfahrungen gemacht, weil man während der Entwicklung eben nicht mehr ständigen Medienbrüchen und Paradigmenwechseln ausgesetzt ist. Auch die Wiederverwendung von Code, z.B. für die Validierung auf Client- und Serverseite, ist ein nicht zu verachtender Vorteil. Bei dem Rest stimme ich vollkommen zu – die Entwicklung “richtiger” Projekte mit JavaScript ohne statische Typisierung, ob nun mit TypeScript oder Flow, ist nicht zu empfehlen – und selbstverständlich muss JavaScript seine Industriereife in den nächsten Jahren in der Breite beweisen. Dass das bei den Technologieriesen bereits geklappt hat, ist aber bereits ein gutes Zeichen.

    Zu 4.)
    Ich habe nicht behauptet, dass dort ausschließlich Node.js eingesetzt wird, sondern das Node.js ein “fester Bestandteil der Systemarchitektur ist”. Und wie ebenfalls im Interview erwähnt, eignet sich Node.js nicht für alle Anwendungsfälle weshalb der konkrete Einsatzbereich natürlich zu überprüfen ist.

    Zu 5.)
    Auch das habe ich nicht gemacht und werde ich niemals tun. Technologische Entscheidungen müssen stets abhängig vom Anwendungsfall getätigt werden. Ich muss hier aber hinzufügen, dass ein komplettes Verschließen vor diesen Technologien auch nicht der richtige Weg ist.

    Viele Grüße

    Sven

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.