Vi siete mai chiesti qual è il fattore fondamentale del successo di Java? Beh, non è facile individuarne uno in particolare ma, se proprio dovessi scegliere, direi proprio che si tratta della capacità di assumere “mille volti e mille forme diverse”.
I volti sono le <b>specifiche</b>, mentre le forme sono le <b>implementazioni</b>.

Forse ai più esperti questo discorso potrà sembrare banale, ma in realtà la differenza (e l’importanza) di tale distinzione è uno dei concetti cardine che i nuovi adepti di Java devono affrontare quando iniziano a costruire qualcosa che vada oltre i semplici “Hello World”.
Molti si spaventano di fronte ad una tale abbondanza di possibilità, e spesso concludono con la classica frase “Java è troppo complicato”.
Nulla di più sbagliato: Java offre la libertà di scegliere che strada seguire nello sviluppo delle proprie applicazioni, a seconda dei requisiti, delle conoscenze e del budget disponibile.

Facciamo subito un esempio: prima della liberalizzazione del mercato e dell’avvento delle compagnie aeree low cost, volare da Roma a Milano comportava obbligatoriamente l’utilizzo della compagnia di bandiera; nessuna concorrenza, nessuna alternativa.
Ora la situazione è cambiata: si possono sempre utilizzare le linee tradizionali ma, se volete, sono disponibili altre compagnie. Certo, magari in alcune il servizio a bordo non è di qualità ed i biglietti non sono rimborsabili, però non c’è dubbio che a Milano ci arriviate (si spera...). Addirittura, esiste anche qualche compagnia che offre un servizio ancora migliore del precedente, ad un prezzo magari più elevato.

Credo che l’esempio sia sufficientemente chiaro: la specifica è il volo da Roma a Milano (tratta, standard minimi di qualità e sicurezza), mentre le implementazioni sono le compagnie (ovvero il modo in cui il volo è effettuato). A parità di specifica, chiarito cosa vi è garantito, potete scegliere una varietà di possibilità diverse, secondo quanto siete disposti a spendere o del livello di servizio atteso.
In Java, questo si traduce in tre termini: <b>Java Community Process (JCP)</b>, <b>Reference Implementation (RI)</b> e <b>Vendor Implementations</b>.

<b>I mille volti</b>
Nato nel 1998, <a href="http://www.jcp.org/" target="_blank">JCP</a> è l’organismo che ha il compito di emanare le specifiche Java (esempi famosi sono Servlet, EJB, JAXP, JNDI...). Composto dalle maggiori aziende informatiche mondiali (SUN, IBM, HP, BEA, Borland) da organismi indipendenti (Apache Foundation) ma anche da privati, nel tempo ha proposto, valutato, emanato e ratificato un numero di specifiche assolutamente vasto e completo.
Fintanto che non è approvata, tuttavia, una specifica mantiene l’iniziale nome di Java Specification Request (JSR), e si è soliti riferirsi ad essa con un numero (ad esempio, JSR-168), che l’accompagna per tutto il suo ciclo di vita.

E’ da notare che le specifiche non nascono dal nulla, ma sono il frutto di un processo di revisione e studio che, seppur rallentandone a volte un po’ troppo il rilascio, contribuisce a garantirne la più ampia condivisione (data la collegialità delle decisioni), la qualità e soprattutto l’aderenza agli standard. Più precisamente, una volta rese pubbliche, le specifiche costituiscono in tutto e per tutto lo standard ufficiale.

Una volta definite le regole del gioco, il JCP si preoccupa anche di realizzare un’implementazione d’esempio che dimostri l’effettiva realizzabilità di quanto teorizzato nella JSR, e funga da riferimento per tutte le altre realizzazioni successive. Si tratta della <b>Reference Implementation (RI)</b>, di cui l’esempio più famoso è il web container <a href="http://jakarta.apache.org/tomcat" target="_blank">Tomcat</a>, realizzato dalla Apache Foundation in open source.
Le RI sono generalmente gratuite (anche perché hanno la funzione di illustrare come una specifica dovrebbe essere implementata) e distribuite in open source, insieme a voluminosi manuali di documentazione.

<b>Le mille forme</b>
Qualche lettore potrebbe obiettare che fin qui non c’è molto di nuovo. La standardizzazione delle specifiche è un processo che avviene anche in altri contesti, seppur con livelli decisionali differenti (ad esempio Microsoft, che in genere realizza tutto da sola), ma il risultato sono sempre delle Application Programming Interfaces (API) utilizzabili dai programmatori.
Questo è sicuramente vero, ma il discorso, nel nostro caso, non è ancora terminato.

Grazie al lavoro svolto nel ciclo di vita della JSR, alla disponibilità della RI ed anche grazie a dei kit di verifica compatibilità (<b>Technology Compatibility Kit - TCK</b>), ogni soggetto sul mercato può realizzare la propria implementazione delle specifiche, più o meno performante e/o di qualità.
Ad esempio, un produttore potrebbe utilizzare algoritmi particolarmente efficaci in termini di tempi d’esecuzione, mentre un altro potrebbe concentrarsi maggiormente sugli aspetti di memoria.
L’importante è che sia garantito il rispetto delle interfacce di base (API) definite dalla JSR ed ogni programmatore, potendo scegliere, potrà utilizzare l’implementazione che più preferisce.

E’ proprio per questo che sul mercato esistono contemporaneamente prodotti open source come Tomcat, Jetty, JBoss (gratuiti, ma carenti sotto certi aspetti) e parallelamente siano presenti anche “colossi” come IBM WebSphere, SonicMQ o Weblogic di BEA (tutti a pagamento, ma dall’estrema potenza, configurabilità e supporto).

E’ questa in effetti la vera forza di Java: un rinnovarsi "dal basso" attraverso specifiche sempre nuove, che recepiscono le esigenze del mercato e vengono trasformate in standard. La competizione si scatena, in seguito, sulle implementazioni e... si sa, quando c’è competizione, c’è innovazione.

Veti incrociati
Non sempre, tuttavia, il cammino verso l’approvazione di una JSR è semplice e privo di ostacoli. Sarebbe ingiusto non rilevare certi comportamenti che le aziende più importanti utilizzano per promuovere JSR che (vuoi per interessi di mercato, <b>time to market</b> e compatibilità tecniche) stanno loro particolarmente “a cuore”.
A volte il tutto, a causa di meccanismi messi in gioco da veti incrociati, si traduce in pesanti ritardi nel completamento delle specifiche, come nel famoso caso delle Java Portlet (JSR-168), attese per oltre un anno.

Un altro caso degno di nota si è verificato proprio nell’ultimo mese di Maggio. In fase d’approvazione della JSR-243, riguardante la versione 2.0 della specifica JDO (Java Data Objects - http://java.sun.com/products/jdo), tre votanti (IBM, Oracle e BEA) hanno espresso parere contrario, citando “sovrapposizioni con altre JSR”.
Per la cronaca, la JSR incriminata è di fatto la JSR-220, riguardante la nuova attesissima versione degli EJB (Enterprise Java Beans – http://java.sun.com/ejb), giunta alla terza versione.
I voti contrari non sono infrequenti, ma stavolta quello che ha scatenato un vero e proprio putiferio è stata la nemmeno troppo velata accusa (emersa in parecchi blog e forum in rete, come ad esempio: http://www.theserverside.com/news/thread.tss?thread_id=25695) che le tre aziende abbiano tentato di affossare la specifica JDO per difendere i loro interessi nel mercato dei costosi application server, all’interno dei quali “vivono” gli EJB.

Come si può vedere, dunque, l’apertura al mercato porta alla piattaforma Java senz’altro notevole vantaggio, ma purtroppo, a volte, ne complica anche la crescita verso le direzioni più corrette. Non sempre, infatti, lo standard è la <b>summa</b> delle migliori scelte possibili, ma a volte è il frutto di salomonica diplomazia e compromessi.

Concludendo, si può dire senz’ombra di dubbio che il connubio standardizzazione/mercato sia stato il fattore che ha maggiormente contribuito al successo di Java in questi anni. Un equilibrio molto sottile, che tutti i soggetti coinvolti dovrebbero tentare di mantenere il più possibile in parità, per un florido e produttivo futuro. Sempre in Java, ovviamente.

Alla prossima

Fabrizio Gianneschi (gianneschi AT programmazione DOT it)

<b>Avvenimenti</b>
<a href="http://www.webb.it/" target="_blank">WEBB.IT 2004</a>, Milano, 3-4 Giugno
<a href="http://it.sun.com/education/promo_seminari.html" target="_blank">Seminari SUN gratuiti</a>, varie date
<a href="http://it.sun.com/eventi/jc04/index.html" target="_blank">Java Conference 2004</a>, Milano, 8 Giugno
<a href="http://www.xp2004.org/" target="_blank">XP Conference 2004</a>, Garmisch-Partenkirchen (Germania), 6-10 Giugno
<a href="http://java.sun.com/javaone/" target="_blank">JavaOne</a>, S.Francisco (USA), 28 Giugno-1 Luglio