Come funziona in pratica la manutenzione di OpenJDK?

Questo è spiegato in molti dettagli nella pagina OpenJDK: Proposta di progetto di aggiornamento JDK 7 Q & A

Will this Project serve as the basis for Oracle JDK 7 Update releases?

Yes.

To quote from Joe Darcy's FOSDEM blog post on OpenJDK 6:

In particular, there will not be the same dichotomy between the OpenJDK 7 code base and the 7 update code base as there is between OpenJDK 6 and the 6 update train...

Per mia lettura, sopra essenzialmente significa che le patch e gli aggiornamenti in genere vanno prima in Open JDK e poi, con il minor ritardo possibile, consegnati in Oracle JDK.

Per le patch di sicurezza, l'immagine sembra essere opposta, cioè preferirei che si presentassero prima su Oracle e poi (ancora, con il minor ritardo possibile) su OpenJDK:

Will the 7 Update Project receive security fixes from Oracle?

Yes.

As with OpenJDK 6, security fixes are first kept confidential and applied to a private forest before being pushed to the public forest as part of the general synchronized publication of the fix to affected JDK release trains. In addition, they will not go through the public code review and putback approval process, and their corresponding issues in the Project's issue tracker will not be publicly visible.

When will this Project receive security fixes from Oracle?

The schedule for Oracle Java SE Critical Patch Updates is publicly available.

Security fixes for this Project's source code will be made available in the JDK 7 Update Project around the same time as they're released in products from Oracle...

Per capire meglio i motivi per cui sembrano esserci tanti sforzi per mantenere sincronizzati Oracle e Open JDK, è opportuno dare un'occhiata alla decisione Oracle sul progetto precedente: Spostamento su OpenJDK come implementazione ufficiale di riferimento di Java SE 7 :

...Oracle and the other members of the Java SE 7 Expert Group have been putting the finishing touches to the Java SE 7 specification (JSR 336). In its role as the specification lead, Oracle is responsible for delivering the Java SE 7 Reference Implementation... we are going to provide a Reference Implementation that is based entirely on the OpenJDK open source code and make it available under the GPL open source license.

The role of the Reference Implementation (RI) is to be used as the gold standard for all Java implementations. In order to have an implementation certified as Java SE compatible, an implementor must pass a large number of compatibility tests - the Technology Compatibility Kit (TCK). Furthermore, implementations may be compared to the RI as an additional check of compatibility. Basically, if your implementation has been certified to have the same behavior as the RI then it is Java compatible. For more information on this topic, consult the JCP FAQ.

Historically, Sun always used the Sun JDK as the RI and made it available under the Binary Code License (BCL). This was very convenient for Sun since it meant that its product implementation was compatible by definition. However, it was also confusing since the Sun JDK contained quite a few features that were not part of the standard, such as the Java Plugin. Also, continuing this practice would make things difficult for open source implementors as they would not be able to study and evaluate the official RI source code. (The source code for the Oracle JDK is slightly different from OpenJDK - something we will be addressing moving forward).

With that in mind, Oracle will:

• Create RI binaries based only on the OpenJDK code base.
• Make RI binaries available under the BCL (the normal Java license) for commercial implementors and GPLv2 (with the Classpath exception) for open-source implementors.
• Continue to provide the TCK to commercial licensees, but also update the OCTLA license so that it covers Java SE 7. The latter allows open source implementators gratis access to the TCK to verify their implementations...

Una decisione superiore significa un grande sforzo da inserire nel codice Open JDK, per rilasciare codice ufficialmente verificato, testato, concesso in licenza e conforme. Se si aggiunge che deve essere rilasciato seguendo il programma pubblico concordato, diventa ovvio che tale sforzo sarà più o meno lo stesso di quello precedentemente utilizzato nelle versioni "tradizionali" di Sun / Oracle Java.

Questo rende ragionevole mantenere le basi di codice JDK aperte e Oracle il più vicino possibile: in caso contrario, la duplicazione dello sviluppo e le correzioni per rendere entrambi i progetti compatibili con TCK potrebbero diventare proibitivi.

Sembra che la decisione di utilizzare Open JDK come implementazione di riferimento abbia reso nel migliore interesse di Oracle mantenere il proprio JDK il più vicino possibile in sincronia con Open JDK - fino al rilascio di JDK 7.

Per capire cosa potrebbe motivare Oracle a mantenere la sincronizzazione menzionata ulteriormente, con le versioni di aggiornamento di JDK 7, è meglio dare uno sguardo a Apri il progetto JDK 8 , il cui scopo è descritto in modo molto simile a quello di Open JDK 7:

The goal of this Project is to produce an open-source reference implementation of the Java SE 8 Platform, to be defined by JSR 337 in the Java Community Process.

Per lo stesso ragionamento sopra illustrato riguardo all'implementazione di riferimento di JDK 7, è, ancora una volta, nell'interesse di Oracle mantenere gli aggiornamenti di entrambi i JDK il più possibile sincronizzati.

Più differenze sarebbero tra questi JDK ora, più difficile sarebbe per Oracle rilasciare Java SE 8, a causa della duplicazione degli sforzi necessari per rendere il loro rilascio conforme a TCK. È vero anche il contrario, ovvero quanto più vicini saranno entrambi i progetti, tanto meno sarà necessario lo sforzo per rilasciare entrambe le implementazioni di Java 8.

È mai successo a te di supportare in parallelo due versioni leggermente diverse dello stesso software, indirizzate a diversi client? Se sì, probabilmente ricorderai il desiderio di tenerli entrambi il più vicino possibile e gli inconvenienti che hai riscontrato quando questi non erano sincronizzati. Con i JDK Open e Oracle, è più o meno così, solo su una scala più grande.

Quasi tutte le correzioni dei bug passano direttamente attraverso il progetto OpenJDK e poi nei distributori JVM downstream (Oracle, Azul, RedHat, ecc.)

Un'eccezione è che alcune patch di sicurezza sono state corrette nelle versioni downstream (in particolare Oracle) prima di essere trasferite in OpenJDK. Questo permette i fornitori di aggiornare la maggior parte del mondo con la correzione di sicurezza prima di pubblicizzare la vulnerabilità nel progetto open source.

Alcuni fornitori scelgono anche di non trasferire nuovamente le modifiche in OpenJDK. Ad esempio, sia Google che Twitter hanno modificato le versioni di OpenJDK che usano internamente con correzioni di bug e funzionalità che non sono tornate nel progetto principale di OpenJDK.

HTH