FacesTales-Kolumne

RIP: JSP ist tot!

Lars Röwekamp, Matthias Weßendorf

Zu jeder neuen Java-Servlet-Spezifikation gab es in der Vergangenheit auch immer eine neue Version der JSP-Spezifikation. Mit dem Erscheinen von Servlet 3.0 hat sich das allerdings gewaltig geändert.

Statt einer vollständigen neuen JSP-Version wird es lediglich ein Maintenance Release für die Unified Expression Language geben – mehr nicht. Eine weitere Spezifikation, die traditionell eine starkeAbhängigkeit zu JSP hat, ist die JavaServer-Faces-Spezifikation. Das neue JSF 2.0 setzt explizit auf einer View Declaration Language (kurz: VDL) zur geordneten Kommunikation zwischen JSF Lifecycle und der verwendeten Seitenbeschreibungstechnologie auf. Die Default-Implementierung des abstrakten Kontrakts ist aber nicht JSP, sondern Facelets.

Abb. 1: Geschichte der Spezifikationen

Die Welt vor JSF 2.0

Bereits in den ersten Versionen von JSF wurde deutlich, dass es eine ganze Reihe von Problemen im Zusammenspiel mit JSP als zuständige Rendering-Technologie geben wird. Unverständlicher Weise hielt die JSF Expert Group (kurz: EG) trotzdem starr an JSP als Standard-Rendering-Technologie fest. Hans Bergsten, ehemaliges Mitglied der JSF EG, schrieb unmittelbar nach dem ersten JSF-Release einen Artikel, der auf die bestehenden Defizite aufmerksam machen sollte und in der Community starke Beachtung fand. Neben seiner berechtigten Kritik an dem nicht funktionierenden Zusammenspiel von JSF und JSP enthielt der Artikel vor allen auch Ideen für eine (bessere) Alternative. Der Artikel griff Konzepte von Apache Tapestry auf und übertrug sie auf die JSF-Welt (siehe auch JavaServer Faces. Building Web-based User Interfaces. O’Reilly Media, ISBN-10: 0596005393). Das eigentlich Interessante an dem Artikel war dabei, dass er den Grundstein für das inzwischen etablierte Facelets-Projekt legte. Der Vollständigkeit halber muss gesagt werden, dass JSF mittlerweile dank der 1.2-Spezifikation zwar einige der wesentlichen Probleme der JSP-Integration gelöst hat (z. B. Erzeugen und Rendern des Komponentenbaums). Trotzdem setzen aber mittlerweile viele JSF-1.2-Projekte lieber auf Facelets statt auf JSP!

[ header = Seite 2: JSP: Old School Web Development ]

JSP: Old School Web Development

Ein Grund für die Beliebtheit von Facelets ist sein pragmatischer Ansatz: (X)HTML-Dateien können ohne Aufwand als „Komponente“ extrahiert und innerhalb verschiedener Facelets-Seiten genutzt werden. Dieser Ansatz eignet sich besonders gut, wenn man gezielt bestehende Funktionalität von JavaScript-Bibliotheken, wie jQuery etc., einsetzen möchte.

Wer schon einmal eine echte JSF-Komponente (Tag, Renderer, Komponente, XML etc.) geschrieben hat, kennt die damit verbundenen Fallstricke. JSP hat zwar mit den Tag Files ein ähnliches, aber deutlich schwergewichtigeres Konzept. Der Facelets-Vorteil: XHTML-Dateien können direkt im Browser geöffnet werden; JSPs müssen dagegen auf einem Server ausgeführt werden. Ein weiteres großes Problem von JSP ist, dass es keine eingebaute Templating-Funktionalität besitzt. Daher werden in Projekten oft Hilfslösungen wie Apache Tiles eingesetzt. Mit Facelets besitzt JSF 2.0 dagegen ein erstklassiges Templating:

<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">
...
<div class="navigation">
<ui:insert name="menu"><ui:include src="menu.xhtml" /></ui:insert>
</div>
<div class="container">
<ui:insert name="main">Text</ui:insert>?>
</div>
...
</html>

In normalem XHTML – für jeden Webdesigner lesbar – wird die Struktur der Seite erstellt. Dabei werden verschiedene Bereiche identifiziert, die unterschiedlichen Inhalt enthalten können:

<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
template="WEB-INF/corp/template.xhtml">
<!-- Überschriebener Inhalt-->
<ui:define name="main">
<h:dataTable ...>
...
</h:dataTable>
</ui:define>
</ui:composition>

Über das template-Attribut wird das eigentliche Template referenziert und anschließend lediglich der main-Bereich der Vorlage überschrieben. Der positive Effekt von Facelets bzw. JSF 2.0 ist dabei, dass keine extra XML-Konfiguration, wie bei Tiles oder anderen Template-Frameworks, benötigt wird. Weniger ist mehr! Man spart sich hier zum einen einiges an XML und zum anderen die Abhängigkeit zu einem weiteren (Open-Source-)Framework. Templates are firstclass citizens with JSF 2.0!

Facelets selbst hat neben den bisher genannten noch weitere Vorteile, die allerdings den Rahmen der Kolumne deutlich sprengen würden. Ein Blick in die reichhaltige Dokumentation kann aber nicht schaden.

Und? Was ist mit JSP?

Nun gibt es seit über einem Jahr also ein neues JSF-Release und manch ein Nutzer von JSF und JSP fragt sich zu Recht, was mit seiner bestehenden Anwendung passiert, sobald er auf JSF 2.0 umstellen will (oder muss). Glücklicherweise ist es nicht so, dass eine JSP-basierte JSF-Anwendung nun nicht mehr funktioniert. JSF 2.0 ist rückwärtskompatibel zu JSP 2.1. Die Anwendung kann somit einfach innerhalb eines Java-EE-6-Containers deployt werden. Achtung: Nutzt die Anwendung allerdings JSP und Facelets sowie eigene Facelets-Bibliotheken oder Erweiterungen (z. B. eigene Facelets Tag Handler oder einen gepatchten View Handler), muss die alte Version von Facelets weiterhin mit der Anwendung deployt werden (WEB-INF/lib). Zusätzlich muss die neue Facelets-Version mit dem Context-Param javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER abgeschaltet werden. Grund hierfür ist die Tatsache, dass das alte Facelets-API nicht mehr innerhalb des com.sun.facelets.* Packages liegt, sondern nun fester Bestandteil des JSF-APIs (javax.faces.view.facelets) ist. Wichtige Klassen, wie z. B. TagHandler, haben daher nun ein neues Java Package. Ebenfalls muss die Facelets-1.x-Version immer mit der Anwendung deployt werden, wenn JSF-1.2-Komponentenbibliotheken eingesetzt werden, die zusätzlich Facelets unterstützen. Schließlich erben deren Klassen auch von dem alten Facelets-API.

Neue 2.0-Features nur für Facelets

Wer vor der Überlegung steht, seine bestehende Anwendung auf JSF 2.0 zu portieren, der wird in der Regel auch ein ausgeprägtes Interesse an den neuen Features der JSF-Spezifikation haben. Gerade die einheitliche Behandlung von Ajax oder dem Partial State Saving macht den Einsatz von JSF 2.0 äußerst schmackhaft. Allerdings werden diese neuen Features teuer eingekauft. Sie funktionieren nur mit Facelets. Wer weiterhin JSP nutzen muss, kommt nicht darum herum, eigene Tag-Klassen, z. B. für das <f:ajax>-Tag, zu schreiben. Da dies mit einem erheblichen Aufwand verbunden ist, sollte man diesen Schritt vorab lieber zweimal überdenken.

Fazit

Zwar kann JSP weiterhin genutzt werden, allerdings ist klar, dass JSP seine Zeit hatte und nur aus Gründen der Abwärtskompatibilität noch weiter unterstützt wird. Besonders stark wird die Unwichtigkeit von JSP innerhalb der JSF-Spezifikation dadurch ausgedrückt, dass sämtliche neue JSF Feature nur mit JSF/Facelets 2.0 funktionieren. Die JSF ExpertGroup war endlich mutig genug und hat damit endgültig auch im JSF-Umfeld den offiziellen Rückzug von JSP eingeläutet. Innerhalb von anderen Java-Webframeworks (Struts, Wicket oder Tapestry) hatte JSP schon längst keine Bedeutung mehr – und dies zu Recht! Kurz und knapp könnte man auch sagen: „JSP ist tot!“

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Matthias Weßendorf
Matthias Weßendorf
Matthias Weßendorf arbeitet bei Red Hat, wo er sich mit WebSocket, HTML5 und weiteren Themen rund um das Next Generation Web beschäftigt. Blog: http://matthiaswessendorf.wordpress.com
Kommentare

Schreibe einen Kommentar

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