Websites herunterladen, die JavaServer Faces nutzen

Über JavaServer Faces

JavaServer Faces ist so alt, dass schon der Fund an sich ein Befund ist. Das Framework erschien erstmals 2004 als Teil der standardisierten Java-Plattform für Unternehmensanwendungen und definierte ein Komponentenmodell für serverseitig gerenderte Benutzeroberflächen: Formularzustand, Validierung, Navigation und Ereignisbehandlung werden auf dem Server verwaltet, und HTML entsteht als Ausgabe, statt im Browser zusammengesetzt zu werden. Die Pflege liegt heute bei der Organisation Eclipse Foundation, wo die Spezifikation als Jakarta Faces weitergeführt wird. Das Framework hat damit bereits mehrere der Anbieter überlebt, die es ursprünglich verkauft haben.

Unsere Taxonomie führt das Framework in der Kategorie Web frameworks, und diese Einordnung passt schlecht, was wir lieber offen sagen als verschweigen. Das Rendering findet auf dem Server in Java statt, und die Zuordnung spiegelt wider, wie unsere Kategorien UI-Frameworks allgemein behandeln, und ist keine Aussage darüber, wo der Code läuft. Die Kategorie lässt sich am besten als Regaletikett verstehen und nicht als technische Beschreibung der Laufzeitumgebung.

Was der Einsatz tatsächlich nahelegt, ist eine bestimmte Art von Organisation. Hinter einer Seite, die mit dem Framework gebaut wurde, stehen ein Java-Applikationsserver, ein internes oder beauftragtes Entwicklungsteam, ein Beschaffungszyklus, der in Jahren statt in Sprints gemessen wird, und eine Anwendung, die spezifiziert wurde, bevor Single-Page-Frontends zum Standard wurden. Die Branchen ergeben sich aus diesem Profil: Banken, Versicherungen, öffentliche Verwaltung, Universitäten, Versorgungsunternehmen, Gesundheitsverwaltung und Logistik. Die Seiten selbst sind meist Portale, Self-Service-Konten, Buchungssysteme und interne Anwendungen mit öffentlichem Zugang, keine Marketing-Websites.

Stand Oktober 2026 erkennen wir JavaServer Faces auf 1.049 Websites. Versionsangaben lassen sich nur bei einem Teil dieses Bestands auslesen, und wo das gelingt, verzeichnen wir 3 verschiedene Versionen, wobei Version 2.0 am häufigsten auftaucht. Eine schmale Versionsstreuung ist bei einer installierten Basis dieses Alters schon für sich aufschlussreich. Anwendungen dieser Art werden eher gepatcht als auf eine neue Version gehoben, weil eine Framework-Migration bedeutet, ein System neu zu testen, für das sich eine Aufsichtsbehörde oder ein Prüfer interessiert, und so halten sich Releases weit länger, als die Release Notes des Anbieters vermuten lassen.

Die Lizenzierung verstärkt dieses Muster. Die Implementierung steht unter der Lizenz Apache 2.0 zur Verfügung, daher ist eine erkannte Website niemandes Kunde, und kein auslaufender Vertrag erzwingt je eine Entscheidung. Eine Anwendung kann viele Jahre unverändert bleiben, ohne dass jemand verpflichtet wäre, sie anzufassen, und genau deshalb wollen Modernisierungsberatungen, Anbieter von Applikationsservern, Sicherheitsteams und Personaldienstleister wissen, wo die verbliebenen Installationen laufen.

Die Erkennung stützt sich auf Spuren im ausgelieferten HTML: Ressourcenpfade des Frameworks, versteckte View-State-Felder und die URL-Suffixe, die das Servlet-Mapping erzeugt. Was vollständig hinter einem Login liegt, zeigt einem Crawler nichts davon, daher ist der sichtbare Bestand kleiner als der tatsächliche und zu Organisationen hin verzerrt, die eine öffentlich zugängliche Seite auf diesem Stack behalten haben. Die Liste ist somit eine Untergrenze, und ihre Zusammensetzung ist wichtiger als die Gesamtzahl.

Eine Abfrage pro Domain zeigt, dass ein einzelner Versicherer das Framework einsetzt. Der Datensatz klärt die Fragen, die sich erst über einen ganzen Bestand stellen: wie viele Portale des öffentlichen Sektors in einem bestimmten Land es noch ausliefern, auf welche Endungen es sich konzentriert, welche Applikationsserver und Frontend-Bibliotheken daneben laufen und ob die installierte Basis zwischen zwei Snapshots schrumpft oder einfach stillsteht.