Introduzione
Quando, nell’ottobre del 2016, MokaByte “festeggiò” i 20 anni passati dalla pubblicazione del suo primo numero, molti autori “storici” scrissero un contributo raccolto in uno speciale tuttora on-line [1]. Al di là delle legittime nostalgie presenti nei ricordi di alcune delle firme che più hanno contribuito a questa rivista, in più di un intervento veniva messo in luce come, oltre a tutti i cambiamenti tecnologici e sociali avvenuti in questi 20 anni, sul processo di evoluzione di Java avesse molto pesato l’acquisizione da parte di Oracle, datata 2010, e il conseguente processo di “chiusura” e “accentramento” che il colosso dei database, e ora anche del cloud, aveva imposto alle pratiche di impronta open source favorite invece dal Java Community Process (JCP).
Più di un autore non mancò di mettere in luce la “pesantezza” assunta negli anni da Java, in particolare dalla versione Enterprise Edition (Java EE), utilizzando la metafora di Mike Milinkovich, il direttore esecutivo della Eclipse Foundation, che ha dichiarato più volte come Java sia un po’ il COBOL dei nostri tempi. E in diversi, nonostante tutto, sottilineavano come le critiche che a suo tempo ebbe Sun Microsystems nulla fossero al confronto delle lamentele nei confronti della politica aziendale di Oracle.
Java SE e Java EE
Ha avuto i suoi significativi intoppi, ma ha seguito un suo itinerario di evoluzione e rilascio la piattaforma SE di Java. Una buona sintesi della storia e delle caratteristiche, aggiornata alla versione 7 ma già proiettata verso la 8, fu pubblicata a suo tempo [2] come eBook da MokaByte. E, sempre ad opera di Luca Vetti Tagliati, erano stati pubblicati due articoli che ben spiegavano le caratteristiche di Java SE 9 [3] [4] nonché tutto il percorso accidentato che conduce a questo importante caposaldo.
Irto di ostacoli, rallentamenti, abbandoni e rinvii, invece, è stato l’itinerario che ha interessato la piattaforma Enterprise Edition, al punto che, da più parti e a più riprese, il rilascio della versione 8 di Java EE è stato dato per fallito. In effetti, non sono mancati ritardi, annunci, ripensamenti, rotture, e così via, che hanno davvero messo in dubbio la riuscita di questo progetto.
Luglio 2017, cioè il mese di uscita di questo numero di MokaByte, dovrebbe essere quello decisivo nella “ripartenza” del rilascio di Java EE 8, almeno a quanto annunciato ufficialmente. Ma prima di arrivare a vedere la proverbiale “luce in fondo al tunnel”, ripercorriamo il tratto di viaggio che si è svolto “in galleria” cercando di capire quali sono stati i problemi incontrati e le ragioni che li hanno generati.
Java EE 8: un percorso a ostacoli
È indubbio che l’incorporazione di Java nel “calderone” degli asset di Oracle, avvenuta nel 2010, ha segnato un momento di svolta, e di rallentamento, nella progressione dei progetti che ricadevano sotto quell’ombrello.
Non si è trattato di un “dispetto” fatto specificamente a Java, sia chiaro. Molte iniziative passate da Sun a Oracle hanno infatti subito sorte analoga, se non peggiore, vista la tendenza di Oracle a ritirare gradualmente fondi e impegno dallo sviluppo di tecnologie condotte sostanzialmente da community con criteri di ispirazione open source. Infatti, in breve, progetti come OpenSolaris e poi OpenOffice sono stati abbandonati senza tanti complimenti. Ma questo ridimensionamento, o riorganizzazione o razionalizzazione, delle iniziative ha finito per ripercuotersi pesantemente anche su tutto il percorso di Java, in particolare per la vesione Enterprise Edition.
Battaglie legali
A parziale “scusante” del disinteresse di Oracle per lo sviluppo di Java EE nel corso degli ultimi sette anni, va ricordato che il colosso dei database ha dovuto riservare a Java un altro tipo di impegno, fatto di tempo, denaro ed energie spese in un contenzioso legale che l’ha opposta — e continua ad opporla — a Google. Con il sistema legale statunitense, queste sono cause che vengono risolte in tempi “brevi” se paragonati ai tempi della giustizia italiana, ma che comunque non sono immediati e possono prendere alcuni anni, specie se, come in questo caso, si tratta di un caso piuttosto controverso.
In breve, e semplificando in maniera brutale, Oracle ha affermato esisteva un suo diritto di proprietà sulle API Java che sono state usate da Google per scrivere il codice usato da Dalvik, la Virtual Machine per Android. Google ha risposto che non si trattava di infrazione a un qualche copyright, ma di un riuso appropriato ammesso dalle licenze e dalla situazione.
I giudici hanno inizialmente dato ragione a Google, ma ben presto il verdetto è stato ribaltato [5] e si è attualmente ancora in contenzioso per cercare di dirimere la questione. Ricordiamo che la posta in gioco non è un generico “Visto? Avevamo ragione noi!” ma una ben più sostanziosa somma di denaro che eventualmente Google dovrà corrispondere ad Oracle per rifondere l’infrazione al diritto di proprietà.
Le scelte di Oracle, le reazioni della comunità
Il contenzioso legale ha sicuramente rafforzato certe scelte di Oracle nei confronti di Java: accentramento e micromanagement dei progetti, tendenziale riduzione del ruolo delle comunità trovano un motivo anche nel fatto che, in caso di vittoria nella causa, l’azienda sarebbe la destinataria esclusiva del risarcimento, e parliamo di cifre dell’ordine del miliardo di dollari e più.
Ma non si può vedere solo in questo aspetto la ragione per cui, in modo abbastanza repentino, l’acquisizione di Sun da parte di Oracle ha sancito un cambiamento sensibile nelle politiche di sviluppo dei prodotti da parte di Oracle.
Per carità, non è che Sun fosse il paradiso e, specie negli ultimi travagliati tempi della sua esistenza, certi problemi si erano fortemente riverberati sull’avanzamento di Java, con grande disappunto da parte della community.
Cambiamenti drastici
Però, con Oracle, si è visto fin da subito che la musica era cambiata per quanto riguardava i progetti open source e community-driven. In un periodo che va, grosso modo, da inizio del 2010 ai primi mesi del 2011:
- Molti progetti open source non immediatamente “monetizzabili” furono sospesi o messi in condizione di spegnersi lentamente a causa di mancanza di fondi (segnatamente, OpenSolaris e OpenOffice); parte del personale che lavorava a questo tipo di progetti preferì migrare verso lidi più accoglienti.
- James Gosling, il “padre” di Java, lasciò l’azienda, deluso per le scelte fatte da Oracle.
- Il Java Community Process vide l’abbandono della Apache Foundation.
- Venne annunciato il rilascio di estensioni proprietarie per MySQL (asset Sun passato in Oracle), con la trasformazione del progetto a un modello “open core”.
Accanto a questi e altri avvenimenti, si verificò lo spostamento su altri progetti di molti impiegati che lavoravano a Java EE con la conseguenza che molti dei team che seguivano il suo sviluppo da anni vennero di fatto smembrati o privati di adeguati fondi.
Reazioni significative
La natura delle scelte di Oracle, con un processo decisionale poco condiviso e fortemente governato da obiettivi di mercato immediati, fu da alcuni definita senza mezzi termini “mercenaria”.
Abbandoni illustri, come quello del già citato James Gosling, non furono privi di polemiche e comunicati secchi [6] e commenti poco favorevoli ai nuovi “padroni del vapore”.
Si formarono inoltre delle iniziative critiche ma propositive, come quella dei Guardiani di Java EE [7], il cui scopo consisteva nel monitorare costantemente ciò che veniva fatto — e non fatto — a livello di avanzamento dei lavori, con tanto di dati sul numero di risoluzioni di problemi e di code commit che si riducevano in maniera costante con il passare degli anni. Il portavoce dei Java EE Guardians, va rimarcato, è anch’egli un transfuga di Oracle che si è trovato male nella nuova azienda.
Il desiderio, neanche tanto recondito, di questo tipo di iniziative era che, se non veramente interessata, Oracle si facesse da parte, lasciasse perdere Java EE 8 e donasse il codice e le licenze a una fondazione open source. Chiaramente la cosa appariva piuttosto difficile, visto che comunque Java resta un asset importantissimo, dal momento che molti grandi progetti, e tanto software attualmente usato nel mondo, girano grazie a Java, e fanno affidamento sulla piattaforma Enterprise Edition.
Potranno non essere “accattivanti” come molte altre tecnologie che attualmente vanno per la maggiore, potranno essere “il COBOL del XXI secolo”, ma di fatto Java SE e Java EE sono piattaforme che ritroviamo un po’ dappertutto e che, nei venti anni trascorsi dalla nascita del linguaggio, hanno finito per diventare cruciali in molte soluzioni IT a livello globale. Lasciare invecchiare male questa tecnologia o, peggio, non curarsi della sua possibile “morte” rappresenterebbe un rischio enorme, che né la comunità di chi le adotta, né tantomeno Oracle possono permettersi di affrontare. Questo presuppone investimenti in denaro e attenzione.
Una lenta ripartenza
Dopo i rallentamenti di cui abbiamo parlato e i numerosi e reiterati rinvii, a partire dalla seconda metà del 2016 è sembrata profilarsi all’orizzonte una ripresa di interesse per Java EE da parte di Oracle. Va ricordato che, secondo i piani iniziali, proprio il terzo trimestre del 2016 avrebbe dovuto vedere il rilascio finale e definitivo della versione 8.
Partiamo da alcune considerazioni generali: negli scorsi anni, i profitti di Oracle sono comunque cresciuti, e non bisogna dimenticare che i due CEO dell’azienda sono tra i più pagati in assoluto nel panorama tecnologico. Il business che ha avuto sempre maggiore sviluppo è stato quello dei servizi cloud che è stato spinto fortemente, impiegando in quei progetti anche gran parte del personale e delle risorse che doveva occuparsi di Java EE.
Oracle ha una struttura “elefantiaca”, prende decisioni in maniera lenta, ma quando lo fa poi tende a portare a termine quanto stabilito. Inoltre ha manifestato nei confronti di Java un atteggiamento di accentramento e un tentativo di controllo rigido, ad esempio piazzando suoi impiegati nei ruoli chiave del Java Community Process, o facendo “cadere dall’alto” una serie di specifiche a cui la comunità doveva sostanzialmente adeguarsi: questi comportamenti sono sicuramente criticabili in un’ottica open source e agile, ma probabilmente indicano che l’interesse strategico per Java c’è ancora e non solo per i motivi legati alla causa legale con Google e al potenziale incasso miliardario del risarcimento.
Dichiarazioni di intenti
Di fatto, dopo mesi e mesi di silenzio sul tema, circa a metà 2016 fa Oracle rilasciò un comunicato, riportato anche sul sito dei Java EE Guardians [7] in cui si dichiarava ancora impegnata sul fronte Java, e con un precisa idea di cosa ci sarebbe stato nelle specifiche per Java EE 8. Nel comunicato, poi si citavano esplicitamente i microservizi, i container sul cloud e le architetture distribuite, manifestando quindi l’intenzione di restare allineati alle attuali tendenze IT.
A queste affermazioni, hanno poi fatto seguito, a partire dall’inizio di questo anno, svariati altri comunicati sullo “stato di avanzamento dei lavori” pubblicati su The Aquarium, uno dei blog ufficiali di Oracle: anche se i tempi inizialmente annunciati a febbraio per la Final Release, cioè luglio 2017, si sono ulteriormente allungati (si parla adesso di fine anno), è però chiaro che le attività sono riprese e stanno procedendo [8] [9] [10]. Anche se con un ritardo significativo, possiamo però dire che Java EE 8 vedrà finalmente la luce.
Java EE 8: vicini alla meta
Uno degli aspetti non secondari del “rilancio” nello sviluppo di Java EE 8 è stato il passaggio del codice su GitHub. Qualcuno ha fatto notare poi che, se non altro, tutto questo ritardo consentito di prendere in seria considerazione tutti gli aspetti legati al cloud — settore considerato strategico da Oracle — ormai giunto a maturità.
Lo stato delle diverse specifiche
Le ultimissime notizie, relative all’appena concluso mese di giugno 2017, ci dicono che JSON-B (JSR 367), JSON-P 1.1 (JSR 374), JSF 2.3 (JSR 372) e JPA 2.2 (JSR 338), relative a Java EE 8, ormai sono passate alla Final Release.
JSR 366, ossia la specifica generale di Java EE 8, è pronta per passare allo stato di Proposed Final Draft.
Sempre allo stato di Proposed Final Draft ci sono anche le specifiche relative a Servlet 4.0 (JSR 369), JAX-RS 2.1 (JSR 370) e Bean Validation 2.0 (JSR 380).
La Security API (JSR 375) sta chiudendo la fase di Public Review Ballot e, se tutto procederà bene, presto paserà anche essa in stato di Proposed Final Draft.
Un quadro completo, specifica per specifica, può essere ricostruito grazie alle ricerche per JSR possibili sul sito del JCP [11].
Insomma, anche se mancano ancora dei passi importanti, è chiaro che il processo di revisione delle specifiche Java EE 8 ha finalmente imboccato la strada verso il completamento.
Conclusioni
Un percorso travagliato, contrassegnato da scelte aziendali piuttosto rigide, aspetti “congiunturali”, rapidità di evoluzione del panorama tecnologico e naturali avvicendamenti ha fatto sì che la versione 8 della piattaforma enterprise di Java sia arrivata in qualche momento a rischiare grosso nel suo processo di realizzazione.
Le ultime notizie e il ritmo dei lavori degli ultimi mesi, invece, sembrano assicurare che, pur con tutti i ritardi del caso, Java EE 8 vedrà la luce in tempi non troppo lunghi.