© StonePictures/Shutterstock.com
Kolumne: Enterprise Tales

Kolumne: Enterprise Tales


Vor einiger Zeit habe ich eine Kolumne zu Reactive Programming in Java 9 und Spring 5 geschrieben und dabei auch kurz betrachtet, was passieren müsste, damit dieses Konzept Einzug in Enterprise Java halten kann. Auf technischer Ebene müsste vor allem die Bindung eines Requests an (nur) einen Thread überwunden werden. Grundsätzlich ist asynchrone Verarbeitung zwar mit Servlet 3.0 möglich, viele Java EE Specs verlassen sich aber noch darauf, dass die Verarbeitung eines Requests auch nur in einem Thread stattfindet. Ist das einmal nicht der Fall, kann es durchaus sein, dass relevanter Kontext fehlt. Soll also das Programmierparadigma der reaktiven Programmierung in den Enterprise-Java-Standard aufgenommen werden, gibt es hier noch einige offene Punkte.

Kürzlich habe ich zufällig ein altes Java Magazin aus dem Jahr 2005 in den Händen gehalten. Damals war das neueste Programmierparadigma die aspektorientierte Programmierung. Von aspektorientierter Programmierung spricht heute niemand mehr (explizit), was die Frage aufkommen lässt, ob es der reaktiven Programmierung in zehn Jahren nicht ähnlich gehen wird. Nun ist es nicht so, dass die aspektorientierte Programmierung seinerzeit Eingang in Java SE oder Java EE fand, jedenfalls nicht explizit. Deshalb ist die Frage gerechtfertigt, ob jede Technologie und jedes neue Programmierparadigma blind in den Standard übernommen werden sollten.

Ohne Praxistest läuft in Sachen Standard nichts

In Zeiten von aspektorientierter Programmierung war es noch gängiges Vorgehen, dass Enterprise Java am Reißbrett entstand (und damit fernab der Realität der meisten Projekte), was unter anderem ja auch dazu geführt hat, dass J2EE (so hieß der Enterprise-Java-Standard damals noch) in der Praxis nicht mehr verwendet wurde. Stattdessen wurden neue Projekte in der Regel mit dem Spring Framework umgesetzt. Mittlerweile hat sich die Welt hier weitergedreht. Das Spring Framework ist immer noch ein Innovationstreiber. In den Enterprise-Java-Standard schaffen es aber nur Dinge, die entweder schon praxiserprobt sind oder zumindest von der Community vehement gefordert werden, wie das in Java EE 8 neu hinzugekommene Security-API [1].

Bei Reactive Programming ist bisher beides nicht der Fall. Der gemeine Enterprise-Java-Entwickler weiß mittlerweile, wie er ausreichend performante Webapplicationen schreibt, die klassischerweise einen Thread pro Request blockieren und dadurch auch deutlich einfacher zu debuggen sind als eine vergleichbare Anwendung, ...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang