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 chedere 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 http://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.
|