JMS 2.0 bietet Entwicklern die lang erwartete Modernisierung

Runderneuert

Thilo Frotscher


Java hat seitdem einen weiten Weg zurückgelegt und viele mächtige Erweiterungen erhalten, sowohl als Sprache als auch als Plattform. So wurde die Sprache etwa um Generics, Enumerations und Annotations erweitert. Zudem gibt es nun try-Statements mit automatischer Verwaltung von Ressourcen. Was die Java-EE-Plattform angeht, so brachte Java EE 5 zunächst einige deutliche Vereinfachungen für Entwickler. Zu den wichtigsten Stichpunkten zählten hier „Convention over Configuration“, der überwiegende Verzicht auf Checked Exceptions sowie der breite Einsatz von Annotations. Mit Java EE 6 hielt dann auch Dependency Injection Einzug in die Plattform.

Von alledem kam JMS lediglich Dependency Injection zugute. So können Ressourcen wie Connection Factory, Queues oder Topics inzwischen injiziert werden. Davon abgesehen fühlen sich Entwickler, die JMS-Anwendungen entwickeln, beim Schreiben des Codes jedoch in lange vergangene Zeiten zurückversetzt. Der Code fühlt sich umständlich an. Und es ist fast schon unglaublich, wie viele Codezeilen notwendig sind, nur um eine einzige Nachricht zu senden oder zu empfangen. Dies fällt ganz besonders dann auf, wenn man die restliche Anwendung mit aktuellen APIs entwickelt.

Doch Abhilfe ist endlich in Sicht. Denn im Zuge der Arbeiten für Java EE 7 wurde nun auch eine Modernisierung des JMS-API beschlossen (JSR-343). Kurz vor Ende des Jahres 2012 liegt die Spezifikation zwar noch immer im Early Draft vor. Da die Fertigstellung von Java EE 7 jedoch für Ende April 2013 geplant ist und zu diesem Zeitpunkt folglich auch JMS 2.0 fertiggestellt sein muss, lohnt sich bereits jetzt ein Blick auf die zu erwartenden Änderungen. Dabei sollte jedoch bedacht werden, dass sich das eine oder andere bis dahin durchaus noch ändern kann.

Warum umständlich, wenn’s auch einfacher geht?

Wo die Probleme des aktuellen API liegen, wird durch einen Blick auf Listing 1 deutlich. Für den einfachen Versand einer Nachricht sind unglaubliche 13 Zeilen Code notwendig. Das ist unter anderem dadurch begründet, dass Ressourcen explizit geschlossen werden müssen und viele API-Methoden Checked Exceptions werfen, die vom Entwickler zu behandeln sind. Zudem sind vor dem eigentlichen Nachrichtenversand mit Connection, Session und TextMessage zunächst eine ganze Reihe von „Zwischenobjekten“ zu erzeugen.

Eine umfassende Vereinfachung des API stand daher ganz oben auf der Wunschliste für JMS 2.0. Da andererseits die Rückwärtskompatibilität gewahrt werden soll, ist eine Vereinf...

JMS 2.0 bietet Entwicklern die lang erwartete Modernisierung

Runderneuert

Thilo Frotscher


Java hat seitdem einen weiten Weg zurückgelegt und viele mächtige Erweiterungen erhalten, sowohl als Sprache als auch als Plattform. So wurde die Sprache etwa um Generics, Enumerations und Annotations erweitert. Zudem gibt es nun try-Statements mit automatischer Verwaltung von Ressourcen. Was die Java-EE-Plattform angeht, so brachte Java EE 5 zunächst einige deutliche Vereinfachungen für Entwickler. Zu den wichtigsten Stichpunkten zählten hier „Convention over Configuration“, der überwiegende Verzicht auf Checked Exceptions sowie der breite Einsatz von Annotations. Mit Java EE 6 hielt dann auch Dependency Injection Einzug in die Plattform.

Von alledem kam JMS lediglich Dependency Injection zugute. So können Ressourcen wie Connection Factory, Queues oder Topics inzwischen injiziert werden. Davon abgesehen fühlen sich Entwickler, die JMS-Anwendungen entwickeln, beim Schreiben des Codes jedoch in lange vergangene Zeiten zurückversetzt. Der Code fühlt sich umständlich an. Und es ist fast schon unglaublich, wie viele Codezeilen notwendig sind, nur um eine einzige Nachricht zu senden oder zu empfangen. Dies fällt ganz besonders dann auf, wenn man die restliche Anwendung mit aktuellen APIs entwickelt.

Doch Abhilfe ist endlich in Sicht. Denn im Zuge der Arbeiten für Java EE 7 wurde nun auch eine Modernisierung des JMS-API beschlossen (JSR-343). Kurz vor Ende des Jahres 2012 liegt die Spezifikation zwar noch immer im Early Draft vor. Da die Fertigstellung von Java EE 7 jedoch für Ende April 2013 geplant ist und zu diesem Zeitpunkt folglich auch JMS 2.0 fertiggestellt sein muss, lohnt sich bereits jetzt ein Blick auf die zu erwartenden Änderungen. Dabei sollte jedoch bedacht werden, dass sich das eine oder andere bis dahin durchaus noch ändern kann.

Warum umständlich, wenn’s auch einfacher geht?

Wo die Probleme des aktuellen API liegen, wird durch einen Blick auf Listing 1 deutlich. Für den einfachen Versand einer Nachricht sind unglaubliche 13 Zeilen Code notwendig. Das ist unter anderem dadurch begründet, dass Ressourcen explizit geschlossen werden müssen und viele API-Methoden Checked Exceptions werfen, die vom Entwickler zu behandeln sind. Zudem sind vor dem eigentlichen Nachrichtenversand mit Connection, Session und TextMessage zunächst eine ganze Reihe von „Zwischenobjekten“ zu erzeugen.

Eine umfassende Vereinfachung des API stand daher ganz oben auf der Wunschliste für JMS 2.0. Da andererseits die Rückwärtskompatibilität gewahrt werden soll, ist eine Vereinf...

Neugierig geworden?


    
Loading...

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