La questione che viene posta è la seguente: è corretto che una versione di manutenzione, che avrebbe dovuto portare piccole migliorie, sia poi cresciuta fino a diventare una vera e propria versione delle API per i contenuti dinamici per il Web? In altre parole, le modifiche apportate valgono così tanto da giustificare una nuova versione?
Nel settembre 2005 il gruppo di manutenzione del JCP ha rilasciato una serie di modifiche alle specifiche delle Servlet, che sono state riprese e discusse all‘inizio di quest‘anno, prima in un articolo di JavaWorld, e poi su TheServerSide.com. Queste modifiche sono raccolte sotto il JSR 154.
La questione che viene posta è la seguente: è corretto che una versione di manutenzione, che avrebbe dovuto portare piccole migliorie, sia poi cresciuta fino a diventare una vera e propria versione delle API per i contenuti dinamici per il Web? In altre parole, le modifiche apportate valgono così tanto da giustificare una nuova versione? Per provare a dare una risposta a questa domanda è opportuno analizzare, anche sommariamente, quali sono state le variazioni effettuate.
Un taglio con il passato
Si può dire che le Servlet 2.5 diano un netto taglio con il passato. Una delle modifiche principali infatti è relativa all‘utilizzo delle annotazioni, una delle funzionalità più recenti del linguaggio Java (versione 5.0). Come si saprà , questa permette di aggiungere marcatori al codice Java che indicano al contenitore di seguire un determinato comportamento. Le annotazioni non sono codice, ma marcano il codice in modo che il contenitore alteri il proprio comportamento di conseguenza. Il linguaggio stesso definisce pochissime annotazioni, oltre ovviamente al fatto che questi nuovi elementi sono supportati dalla sintassi. Le annotazioni che è possibile utilizzare nel codice sono infatti definite in JSR appositi. Un semplice esempio di annotazione è illustrato nel listato seguente, che non è altro che l‘implementazione di un semplicissimo Web Service. Le annotazioni utilizzate sono definite nel JSR 181:
import javax.jws.WebService;import javax.jws.WebMethod;@WebServicepublic class HelloWorldService {@WebMethodpublic String helloWorld() {return "Hello World!";}}
Caricando questa classe in un contenitore apposito, che ne riconosca il significato, si ottiene un servizio Web già pronto, senza la necessità di codificare parti di codice che supportino SOAP.
In merito alle Servlet, l‘elenco delle annotazioni non è ancora disponibili, ma le principali sono le seguenti:
- @Resource e @Resources permettono di eliminare il codice JNDI. Marcando un campo con questa annotazione, il contenitore si preoccupa di valorizzare la variabile con la risorsa richiesta, prima che la Servlet venga attivata. @Resources è come @Resource, con la differenza che permette di gestire un vettore di risorse.
- @PostConstruct e @PreDestroy permettono di rendere metodi personalizzati della Servlet parte del ciclo di vita. Sostanzialmente consentono di definire metodi init() e destroy() alternativi. Questi possono essere utilizzati per inizializzare e distruggere risorse attivate tramite @Resource.
- @EJB, @PersistenceContext, @PersistenceContexts, @PersistenceUnit e @PersistenceUnits permettono di operare con EJB3. In particolare la prima annotazione permette di valorizzare un campo con un riferimento ad un EJB.
Tante piccole modifiche
Oltre alla funzionalità più eclatante, l‘utilizzo delle annotazioni, le nuove specifiche includono una serie di modifiche minori:
- possibilità di utilizzo di wildcard per il mapping delle servlet e dei filtri.
- Rimozioni di restrizioni per la gesitione degli errori e per la gestione della sessione. In particolare, le pagine di errore configurate in web.xml con il tag
ora possono chiamare il metodo setStatus().
- Chiarificazioni varie, relative alle intestazioni, all‘encoding ed alle sessioni.
Ma l‘appettito vien mangiando, ed ancora adesso, nella lista dei desiderata, sono presenti molte idee. Purtroppo, la natura dell‘intervento sulle specifiche è di pura revisione, quindi modifiche più corpose sono state postposte, forse alla versione 3.0 delle specifiche. Bisogna anche notare che molto del tempo dedicato allo sviluppo del JSR 154 è stato dedicato ad assicurarsi che le specifiche funzionassero bene con gli altri elementi di quel grande puzzle che è Java EE 5.0.
Networking ad altre prestazioni
Forse l‘elemento più essenziale che il gruppo di sviluppo del JSR 154 ha dovuto rimandare alla prossima versione delle specifiche è l‘utilizzo del package NIO, le nuovi API Java per la comunicazione asincrona.
La presenza della sola comunicazione sincrona è stata sempre un cruccio per la piattaforma Java, che le ha impedito di scalare facilmente le applicazioni al fine di supportare un numero considerevole di utenti. Il classico approccio “un thread – una connessione”, proposto nelle prime versioni dei server di rete scritti in Java, infatti, ha il fastidioso problema di esaurire presto nel risorse disponibili. Con NIO è possibile ovviare a questo problema, ma ancora le Servlet non ne fanno uso. E probabilmente non ne faranno uso fino a Java EE 6.0.
Gli sviluppatori di Jakarta Tomcat hanno fatto un lavoro eccellente nell‘implementare il proprio Servlet Contaniner senza utilizzare NIO, ottenendo comunque performance di tutto rispetto, dato che questo software open source è integrato in JBoss, che si propone anche come strumento pronto per la produzione. Purtroppo ci sono anche casi in cui questo non è sufficiente, come nel caso della piattaforma di gaming condiviso brasiliana MegaJogos. Altri containter, come Jetty, hanno migrato a NIO principalmente per problemi di prestazioni. Ma questo uso rimane dietro le quinte, perché le API delle Servlet volutamente, per ora, non presuppongono l‘uso di NIO.
Conclusioni
La nuova versione delle specifiche delle Servlet è interessante, ma l‘allineamento con la versione 5.0 del linguaggio significa anche due cose: in primis lo sviluppatore può utilizzare tutte le caratteristiche di questa versione del linguaggio. In altre parole, l‘essere in presenza di un contenitore Servlet 2.5 significa automaticamente avere a disposizione la versione 5.0 di Java. Quindi è possibile utilizzare annotazioni, generici, boxing/unboxing, cicli migliorati, ed altro).
Lo svantaggio è che le funzionalità delle Servlet 2.5 non strettamente legate a caratteristiche di Java 5.0 non saranno disponibili con runtime più datati.
Come sempre, la scelta se saltare sul carrozzone delle nuove specifiche o restare ancorati alle più comprovate versioni precedenti è una decisione che solo chi lavora sul proprio specifico progetto può prendere. Ad ogni modo, sicuramente passerà del tempo prima che le aziende si allineeranno alle nuove versioni, e di conseguenza, nolenti o volenti, anche noi dovremmo comportarci di conseguenza.
Massimiliano Bigatti è sviluppatore senior, autore tecnico e appassionato di fotografia.
Certificato, tra le altre, come SUN Certified Enterprise Architect for Java2 Enterprise
Edition Technology, lavora presso un importante business solution provider.
Nel tempo libero scrive per diverse riviste di informatica e ha scritto una decina di libri,
quasi tutti su Java, tra cui "Java e Open Source", Tecniche Nuove 2005.
Il suo sito personale è raggiungibile all‘indirizzo www.bigatti.it.