In una recente lettera alla comunità di sviluppatori Java [1], SUN ha dichiarato l'intenzione di unificare gli sforzi dei due gruppi di lavoro sulle nuove revisioni della tecnologia EJB e JDO. SUN rappresenta il leader dello sviluppo in entrambi i gruppi di lavoro, quindi questa decisione è perfettamente applicabile. Non solo, è opportuna. Ma cosa si cela dietro a questa decisione?

Figura 1 - Il logo di Java Community Process

Già si sapeva che la nuova versione della tecnologia EJB sarebbe stata, più che una evoluzione, una rivoluzione. Il modello di programmazione sarebbe stato semplificato, allineandosi ad uno schema di persistenza basata su semplici oggetti Java, invece che su mostruose sottoclassi di EntityBean o SessionBean.
L'esempio da seguire è stato, fin dai primi tempi, quello del noto motore di persistenza Hibernate. Come si ricorderà dall'articolo pubblicato su Mokabyte a marzo di quest'anno [2], questo framework è ampiamente utilizzato, semplice e completo, e molto noto tra i programmatori Java. La persistenza avviene su oggetti POJO (Plain Old Java Object), ovvero semplici classi Java.
Interessante notare come un nuovo acronimo - POJO - stia ad indicare non qualcosa di nuovo, ma le vecchie e consolidate normali classi Java. Gli orpelli di EJB e JDO hanno imposto una complessità tale da rendere necessaria la coniazione di un termine per definire la "normalitˆ".

JDO od Hibernate?
Il gruppo di lavoro di EJB si è quindi rivolto alle interfacce di Hibernate come modello da seguire, probabilmente generando qualche attrito con il gruppo di lavoro di JDO. Questa tecnologia di SUN, anche se ancora più complessa di Hibernate, vuole offrire una soluzione allo stesso tipo di problema: la persistenza di normali oggetti Java non inseriti all'interno di un application server.
Appariva dunque strano che, quando il gruppo di lavoro di EJB decise una convergenza verso un modello di persistenza POJO, non fosse stato scelto JDO come base di partenza.
D'altra parte, c'è stato qualche battibecco tra i sostenitori di JDO e l'autore del progetto Hibernate [3]. Quest'ultimo, nel suo blog, ha pesantemente criticato JDO per la complessità, la difficoltà di JDOQL, la gestione del caricamento dei campi. Gli ha risposto per le rime Abe White di Solarmetric, un venditore di soluzioni JDO anche presente nel gruppo di lavoro di JDO2. Insomma, un po' di scontro c'è stato.
Con la recente lettera di SUN, firmata da entrambi i leader delle specifiche EJB3 e JDO2, la situazione si normalizza entro binari prevedibili, con l'accettazione dell'idea di lavorare insieme.
In un futuro dovremo quindi aspettarci un modello comune di persistenza in EJB e JDO, utilizzabile quindi all'interno o all'esterno di un application server, ma con lo zampino di altri attori interessanti... ed interessati.

La forza dell'open source
In entrambi i gruppi di lavoro [4][5], infatti, compaiono due organizzazioni fondamentali del mondo dell'open source, Apache Software Foundation e JBoss Inc. La notorietà della prima è indiscussa, mentre JBoss è in crescita, e sta guadagnando sempre più consensi grazie al suo application server. L'azienda ha assunto l'autore di Hibernate, l'australiano Gavin King, con il compito di integrare il proprio gioiello in JBoss, sostituendo il vetusto sistema di persistenza EJB implementato dall'application server open source. Come noto, JBoss Inc fornisce consulenza ed assistenza su JBoss, e sulle tecnologie collegate, come Tomcat ed - ora - Hibernate.

Figura 2 - Il logo del progetto Hibernate

Insieme a Gavin King lavorano al cuore di Hibernate altri tre sviluppatori. Con un lavoro a tempo pieno, il continuo sviluppo del prodotto è assicurato, come pure la partecipazione di King al Java Community Process. Prima, quest'ultimo fatto sarebbe stato impossibile, visto che l'autore di Hibernate consumava tutto il suo tempo libero a rispondere alle richieste di aiuto degli utenti del suo framework di persistenza.
Grazie alla partecipazione di JBoss Inc al JCP, le API di persistenza di EJB3 stanno evolvendo in qualcosa di molto simile alle API di Hibernate (anche se non saranno disponibili tutte le funzioni del framework di King, che saranno comunque accessibili dalle applicazioni che includeranno i JAR di Hibernate). JDO2, che sarà simile a EJB3, sarà di conseguenza molto simile ad Hibernate. Due piccioni con una fava.

Conclusioni
Fino a poco tempo fa, JBoss e SUN erano ai ferri corti per la storia della certificazione di JBoss Application Server, poi con l'introduzione di Hibernate nel puzzle, sono diventati tutti grandi amici. Non solo JBoss si è certificato come application server conforme a J2EE, ma ora decide anche come evolvere una delle tecnologie chiave di J2EE. Anzi, due.
Chissà quali sono gli accordi tra le due aziende? Forse SUN ha capito che, per affrontare la sfida di .NET è necessario raccogliere a sè tutte le buone idee, continuando l'opera di consolidamento della piattaforma Java, invece che perdersi in campanilismi inutili.

Riferimenti
[1] De Michiel e Russell, A letter to the Java Technology Community, http://java.sun.com/j2ee/letter/persistence.html
[2] M.Bigatti, Motori di persistenza in Java, Mokabyte, http://www.mokabyte.it/2004/03/persistence_engine-1.htm
[3] TheServerSide.COM, EJB3.0 and JDO2.0: views from both sides, http://www.theserverside.com/news/thread.tss?thread_id=25804
[4] JSR-220 (Enterprise Javabeans 3.0), http://jcp.org/en/jsr/detail?id=220
[5] JSR-234 (Java Data Objects 2.0), http://jcp.org/en/jsr/detail?id=243
[6] Debu Panda, Simplifying EJB Development with EJB 3.0, http://www.theserverside.com/articles/article.tss?l=SimplifyingEJB3
[7] Javafree.com.br, Intervista con Gavin King, http://www.javafree.com.br/home/modules.php?name=Content&pa=showpage&pid=41