Un recente scambio di opinioni su blog dedicati a Java hanno messo in luce alcuni aspetti negativi dell‘interazione tra specifiche JCP, comunità degli sviluppatori ed il mondo open source. Ed anche la possibile limitazione delle future evoluzioni di progetti open source.
Nel gruppo di sviluppo di OpenSymphony (http://www.opensymphony.com/) già da qualche tempo serpeggia un po‘ di malumore. I programmatori hanno creato con fatica un completo framework per applicazioni Web, WebWork; lo stanno manutenendo, e forse vorebbero pianificarne liberamente l‘evoluzione.
Magari pensano di avere a disposizione una tecnologia degna di entrare a far parte delle specifiche Java EE. D‘altra parte, già Struts sta collaborando strettamente con il JCP. E forse questo fatto può essere una fonte di risentimento. Ma come, si possono chiedere gli sviluppatori di OpenSymphony, perché loro si e noi no?
Già in passato, con l‘introduzione della sintassi ${}, necessaria a EL e JSTL, gli sviluppatori di OpenSymphony hanno dovuto modificare il loro codice ed utilizzare la sintassi %{} al posto di ${} che utilizzavano in precedenza. Con relativo impatto sul progresso del progetto e la compatibilità verso il passato per gli utenti.
Sostanzialmente le specifiche ufficiali di SUN non sembravano tenere in considerazione la presenza di un tool open source che già utilizzava questa particolare sequenza di caratteri. Un fatto che può essere anche vissuto come “mancanza di rispetto” da parte degli sviluppatori, un mancato riconoscimento dell‘importanza che pensano di avere nella comunità Java nel suo complesso.
L‘altra faccia del Web
Oggi, con le specifiche JSF (di cui abbiamo parlato in precedenza https://www.mokabyte.it/2005/04/faces.htm), una collisione di nomi si ripresenta, ma è più grave. La nuova sintassi #{} è già infatti utilizzata dallo standard OGNL per rappresentare mappe in linea. E questo standard non è utilizzato solo da WebWork (http://www.opensymphony.com/webwork/), ma anche da progetti di Apache, come Tapestry (http://jakarta.apache.org/tapestry/).
Il gruppo di OpenSymphony ha dunque cercato di mediare con il gruppo di sviluppo JCP delle specifiche SUN, in modo da poter almeno disattivare il parsing di espressioni come ${} e #{}. La risposta, però, è stata un secco “no”.
Oggi Java EE 5 è in fase di rilascio per la revisione pubblica e alcuni timori di Patrick Lightbody, di OpenSymphony sono stati confermati. La nuova sintassi è stata inserita, ma pare si possano disabilitare in qualche modo, agendo su web.xml.
A questo punto il giudizio su JSP è diventato netto: come tecnologia generalista di pagine dinamiche per la piattaforma Java, JSP è finito.
Ulteriori evoluzioni?
Il dubbio è infatti quello che le possibili evoluzioni di JSP come tecnologia a se stante vengano fortemente limitate in futuro, nell‘ottica di una maggiore evoluzione di JSF.
Per fare un paragone con il passato, quando non esisteva JSP si doveva lavorare con le Servlet. Quando sono state introdotte le JSP, molto del lavoro che si faceva con le Servlet è stato passato a JSP. Con l‘introduzione di JSTL, si è cambiato decisamente approccio e molto di quello che si faceva in Java all‘interno di JSP è stato passato a JSTL. Ora la nuova frontiera è JSF, e sarà questo il front-end degli utenti verso le tecnologie sottostanti, come JSP e Servlet.
Dal punto di vista di SUN, la maggiore integrazione tra JSP e JSF non è altro che un modo per ottenere una piattaforma più lineare. Dal punto di vista dei progetti open source, è invece una limitazione alla libertà di azione.
In pratica, se prendi il pacchetto Java EE, devi prendere insieme Servlet, JSP, JSTL e JSF, mentre in precedenza l‘approccio era un poco più flessibile.
C‘è poi da considerare che JSF non è una tecnologia molto matura, come già abbiamo avuto di sottolineare su queste pagine, ed una minor flessibilità ad utilizzare strumenti diversi potrebbe diventare un problema.
Chi è il morto?
Ma la sostanza, probabilmente, è che con l‘evolversi della tecnologia Java EE gli spazi liberi che gli strumenti open source possono sfruttare diventano sempre meno. Prima si è persa la sintassi ${}, ora la #{}. Con JSF ora Struts e Tapestry hanno meno importanza. Come con JSTL si perse l‘utilità della Apache Standard Tag Library.
Il malumore di OpenSympony è forse per l‘approccio del tipo “abbraccia ed estendi” che sta facendo SUN. Prende le idee migliori dal mondo open source e le integra come tecnologie standard. Di fatto uccidendo diversi progetti open source.
Infatti, con la disponibiltà di Java EE 5, chi si accollerà l‘onere di scaricare, installare e configurare tool open source come Struts o WebWork, visto che le stesse funzionalità sono già presenti nella piattaforma?
Forse solo gli utenti che devono supportare dei progetti legacy.
No mister Lightbody, forse il morto, se c‘è ne è uno, è WebWork, anche se posso capire che la cosa possa essere molto fastidiosa.
In realtà , probabilmente la partita è ancora aperta. Non penso che JSF oggi possa offrire quello che offre Spring o WebWork, che sono dei completi framework, e non solo una tecnologia. Ed è difficile che a breve SUN possa (e voglia) coprire in modo standard tutte le funzionalità presenti in questi framework.
E la comunità open source?
Ma se il problema può dirsi chiarito, ne rimane un altro, forse più sottile ed a lungo termine. Abbiamo avuto, nel corso dell‘evoluzione della piattaforma Java, una serie di epoche: quella pionieristica (JDK 1.0.2), quella del consolidamento (JDK 1.1), dell‘evoluzione (Java2 Standard Edition 1.2), quella dove ancora si credeva nelle Applet (Java2 Standard Edition 1.3). In parallelo abbiamo avuto un‘epoca di fioritura di strumenti e librerie open source. Oggi viviamo un‘epoca dove queste tecnologie, forse le migliori, o forse le più note, vengono integrate nella piattaforma. E durante questo processo, alcune devono morire. Altre devono cambiare.
È un fatto relativamente nuovo nella comunità Java, mentre probabilmente in quella Unix/Linux si è già avuta qualche esperienza (penso solo all‘enorme fork tra KDE e Gnome, con conseguente duplicazione di tutte le applicazioni, in nome della libertà del software).
Come reagirà la comunità open source Java a questo nuovo modo di operare? Continueranno a supportare la piattaforma? Saranno disposti a cooperare con SUN anche vedendo ridurre il loro spazio di manovra?
Rimaniamo fiduciosi che questo accada, come suggerisce il progetto JSTL. È uno standard SUN, ma l‘implementazione di riferimento è un progetto open source di Apache.