Scaricare i siti web che utilizzano JavaServer Faces

Informazioni su JavaServer Faces

JavaServer Faces ha abbastanza anni perché il solo fatto di trovarlo sia già un’informazione. Rilasciato per la prima volta nel 2004 nell’ambito della piattaforma Java enterprise standard, ha definito un modello a componenti per interfacce utente renderizzate sul server: stato dei moduli, validazione, navigazione e gestione degli eventi affidati al server, con l’HTML prodotto come output anziché assemblato nel browser. Oggi la manutenzione è affidata a Eclipse Foundation, presso cui la specifica prosegue con il nome Jakarta Faces, il che significa che il framework è già sopravvissuto a diversi dei fornitori che lo vendevano in origine.

La nostra tassonomia classifica il framework nella categoria Web frameworks, un’etichetta poco calzante che è meglio segnalare che nascondere. Il rendering avviene sul server, in Java, e il raggruppamento riflette il modo in cui le nostre categorie trattano in generale i framework per interfacce utente, non un’affermazione su dove venga eseguito il codice. Conviene intendere la categoria come l’etichetta di uno scaffale più che come una descrizione tecnica del runtime.

Quello che la presenza implica davvero è un tipo preciso di organizzazione. Dietro una pagina costruita con il framework ci sono un application server Java, un team di sviluppo interno o esterno, un ciclo di acquisto che si misura in anni anziché in sprint, e un’applicazione specificata prima che i front end a pagina singola diventassero la norma. Da qui derivano i settori: banche, assicurazioni, pubblica amministrazione, università, servizi di pubblica utilità, amministrazione sanitaria e logistica. Le pagine in sé sono di solito portali, aree clienti self service, sistemi di prenotazione e applicazioni interne con un ingresso pubblico, non siti di marketing.

A ottobre 2026 rileviamo JavaServer Faces su 3392 siti. L’informazione sulla versione si può ricavare solo per una parte di questa popolazione, e, dove è leggibile, registriamo 3 versioni distinte, tra cui la versione 2.0 è quella ricavata più spesso. Una dispersione ridotta delle versioni su una base installata di questa età è di per sé significativa. Applicazioni di questo tipo vengono corrette con patch anziché aggiornate, perché migrare il framework significa testare di nuovo un sistema a cui tiene un ente regolatore o un revisore, quindi le versioni restano in circolazione molto più a lungo di quanto suggerirebbero le note di rilascio del fornitore.

La licenza rafforza lo schema. L’implementazione è disponibile con licenza Apache 2.0, quindi un sito rilevato non è cliente di nessuno e non c’è mai un rinnovo in scadenza che costringa a prendere una decisione. Un’applicazione può restare invariata per molti anni senza che nessuno sia obbligato a toccarla, ed è proprio per questo che società di consulenza per la modernizzazione, fornitori di application server, team di sicurezza e agenzie per il lavoro vogliono tutti sapere dove si trovano le installazioni rimaste.

Il rilevamento si basa sulle tracce lasciate nell’HTML consegnato: i percorsi delle risorse del framework, i campi nascosti con lo stato della vista e i suffissi degli URL prodotti dalla mappatura delle servlet. Ciò che si trova interamente dietro un login non espone nessuno di questi elementi a un crawler, quindi la popolazione visibile è più piccola di quella reale e sbilanciata verso le organizzazioni che hanno mantenuto una pagina pubblica su questo stack. L’elenco va quindi letto come una stima per difetto, e la sua forma conta più del totale.

Una ricerca per singolo dominio dice che un’assicurazione usa il framework. Il dataset risponde alle domande che esistono solo a livello di popolazione: quanti portali del settore pubblico in un dato paese lo servono ancora, in quali estensioni di dominio si concentra, quali application server e librerie front end gli stanno accanto, e se la base installata si stia riducendo da un’istantanea all’altra o resti semplicemente ferma.