Jakarta EE 10: Das erste große Release seit 5 Jahren zielt auf Cloud-Anwendungen
Seite 3: JSF wird zu Faces
Obwohl viele Anwendungen mittlerweile auf ein JavaScript-basiertes Frontend mit Frameworks wie Angular, React oder Vue.js setzen, ist JSF nach wie vor weit verbreitet. Zum einen, weil es historisch bedingt in den letzten 10 bis 20 Jahren Einzug in viele Enterprise-Anwendungen gehalten hat und dort weiterhin existiert. Zum anderen aber auch, weil nach wie vor etliche Jakarta-EE-Neuentwicklungen im Frontend auf JSF setzen, da für viele Developer im Java-Enterprise-Umfeld JSF einfacher zu verstehen und zu handhaben ist als seine JavaScript-basierten Alternativen. Daher wartet JSF ebenfalls mit einem Update der Spezifikation auf.
Die wohl auffälligste Änderung ist der Name: Ab sofort heißt die Spezifikation nicht mehr Java beziehungsweise Jakarta Server Faces sondern Jakarta Faces oder kurz Faces. Das ist einerseits ein Tribut an die generelle Umbenennung von Java in Jakarta und andererseits hilft es dabei, sich des Kürzels JSF zu entledigen. Intern heißt die Spezifikation seit geraumer Zeit Faces.
Neu ist eine API zum rein Java-basierten Aufbau von Facelets. In der Faces-Community gab es schon immer Vertreter des hundertprozentig Java-basierten Ansatzes. Eine von Facelet abgeleitete Klasse muss lediglich die @View-Annotation tragen und die gewünschten Lifecycle-Methoden implementieren. Folgender Code zeigt den Aufbau einer einfachen View mit der neuen API:
@View("/helloWorld.xhtml")
@ApplicationScoped
public class HelloWorldFacelet extends Facelet {
@Override
public void apply(FacesContext facesContext,
UIComponent root) throws IOException
{
List<UIComponent> rootChildren = root.getChildren();
UIOutput output = new UIOutput();
output.setValue(
"<html xmlns=\"http://www.w3.org/1999/xhtml\">");
rootChildren.add(output);
HtmlBody body = new HtmlBody();
rootChildren.add(body);
...
output = new UIOutput();
output.setValue("</html>");
rootChildren.add(output);
}
}Aktuell ist die API noch minimalistisch gehalten. Abhängig von der Akzeptanz innerhalb der Faces-Community gibt es aber Pläne, sie weiter auszubauen.
Mit der Annotation @ClientWindowScopes existiert ein neuer managed Scope, der denjenigen, die DeltaSpike genutzt haben, bekannt sein dürfte. Der Scope ist in etwa vergleichbar mit @FlowScoped, ist aber nicht auf dedizierte Seiten begrenzt. Stattdessen startet er mit dem automatischen Erstellen einer jfwid zum Identifizieren des aktuellen Window und existiert so lange, wie die ID als Request-Parameter an die Folgeseiten weitergegeben wird.
Interessant sind nicht nur die Neuerungen, sondern auch, was künftig nicht mehr dazu gehört. An erster Stelle ist dabei die Anbindung an Java beziehungsweise Jakarta Server Pages als View-Technik zu nennen. JSPs sind bereits seit JSF 2.0, das 2009 erschienen ist, als überholt (deprecated) markiert, da ihr Lebenszyklus nicht gut zu dem Lifecycle von Jakarta Faces passt. Die Herausnahme aus der Spezifikation ist somit nur konsequent. Ebenfalls entfernt wurden die proprietären JSF Managed Beans, die bereits seit JSF 2.3 als deprecated markiert sind. In der Praxis haben die meisten Projekte sie vermutlich seit Jahren durch CDI Managed Beans ersetzt.
Fehlt da nicht etwas?
Wer sich in den vergangenen Monaten mit den Vorgängen innerhalb der Jakarta Community auseinandergesetzt hat, wird in der Aufzählung der Jakarta-EE-APIs die eine oder andere Spezifikation vermissen.
Neben den offiziellen Spezifikationen der drei Profiles existieren einige weitere Seitenprojekte, die es aus unterschiedlichen Gründen noch nicht in die Spezifikation geschafft haben, aber heiße Anwärter für spätere Versionen wie Jakarta EE 11 oder 12 sind.
Vorneweg steht die Jakarta-Config-API, die das Verwalten und Bereitstellen von Konfigurationsinformationen vereinheitlichten soll. Die API ist stark an die gleichnamige API aus dem MicroProfile angelehnt, die sie aber nach aktuellem Stand nicht ersetzen soll. Ursprünglich sollte die erste Version als Bestandteil von Jakarta EE 10 erscheinen, aber die Spezifikation brachte es innerhalb des recht strengen Zeitplans nicht zur Fertigstellung.
Ebenfalls nicht in das aktuelle Release geschafft hat es die Jakarta-NoSQL-Spezifikation, die eine API zum einfachen und standardisierten Zugriff auf NoSQL-Datenbanken bietet. Die Spezifikation ist nach wie vor "under construction" und sicherlich ein heißer Kandidat für eins der kommenden Jakarta-EE-Releases.
Weitere Kandidaten in der Warteschlange sind derzeit Jakarta Data, Jakarta MVC und Jakarta RPC.
