Risposte:
Questo è spiegato in maggior dettaglio nella pagina OpenJDK: Domande e risposte sulla proposta di progetto di aggiornamento JDK 7
Questo progetto servirà come base per le versioni di aggiornamento Oracle JDK 7?
Sì.
Per citare dal post sul blog FOSDEM di Joe Darcy su OpenJDK 6 :
In particolare, non ci sarà la stessa dicotomia tra la base di codice OpenJDK 7 e la base di codice di aggiornamento 7 che esiste tra OpenJDK 6 e il treno di aggiornamento 6 ...
Secondo la mia lettura, sopra essenzialmente significa che le patch e gli aggiornamenti andranno in genere prima su Open JDK e poi, con il minor ritardo possibile, consegnato in Oracle JDK.
Per le patch di sicurezza, l'immagine sembra essere opposta, vale a dire preferirei che passassero prima alle versioni Oracle e poi (di nuovo, con il minor ritardo possibile) a OpenJDK:
Il 7 Update Project riceverà correzioni di sicurezza da Oracle?
Sì.
Come con OpenJDK 6, le correzioni di sicurezza vengono inizialmente mantenute riservate e applicate a una foresta privata prima di essere inviate alla foresta pubblica come parte della pubblicazione generale sincronizzata della correzione sui treni di rilascio JDK interessati. Inoltre, non passeranno attraverso la revisione del codice pubblico e il processo di approvazione della restituzione e i loro problemi corrispondenti nel tracker dei problemi del Progetto non saranno visibili pubblicamente.
Quando questo progetto riceverà correzioni di sicurezza da Oracle?
Il programma per gli aggiornamenti delle patch critiche di Oracle Java SE è disponibile pubblicamente .
Le correzioni di sicurezza per il codice sorgente di questo progetto saranno rese disponibili nel progetto di aggiornamento JDK 7 nello stesso momento in cui vengono rilasciate nei prodotti di Oracle ...
Per comprendere meglio i motivi per cui sembrano esserci così tanti sforzi per mantenere sincronizzati Oracle e Open JDK, ha senso dare un'occhiata alla decisione Oracle sul progetto precedente: passare a OpenJDK come implementazione ufficiale di riferimento Java SE 7 :
... Oracle e gli altri membri del gruppo di esperti Java SE 7 hanno apportato gli ultimi ritocchi alla specifica Java SE 7 ( JSR 336 ). Nel suo ruolo di responsabile delle specifiche, Oracle è responsabile della consegna dell'implementazione di riferimento di Java SE 7 ... forniremo un'implementazione di riferimento interamente basata sul codice open source OpenJDK e lo renderemo disponibile con la licenza open source GPL .
Il ruolo dell'implementazione di riferimento (RI) deve essere utilizzato come standard di riferimento per tutte le implementazioni Java. Per ottenere un'implementazione certificata come compatibile con Java SE, un implementatore deve superare un gran numero di test di compatibilità: il Technology Compatibility Kit (TCK). Inoltre, le implementazioni possono essere confrontate con il RI come ulteriore controllo di compatibilità. Fondamentalmente, se l'implementazione è stata certificata per avere lo stesso comportamento del RI, allora è compatibile Java. Per ulteriori informazioni su questo argomento, consultare le Domande frequenti su JCP .
Storicamente, Sun ha sempre usato il Sun JDK come RI e lo ha reso disponibile sotto la Binary Code License (BCL). Questo è stato molto conveniente per Sun poiché significa che la sua implementazione del prodotto era compatibile per definizione. Tuttavia, era anche fonte di confusione poiché Sun JDK conteneva alcune funzionalità che non facevano parte dello standard, come il plugin Java. Inoltre, continuare questa pratica renderebbe le cose difficili per gli implementatori open source in quanto non sarebbero in grado di studiare e valutare il codice sorgente ufficiale del RI. (Il codice sorgente per Oracle JDK è leggermente diverso da OpenJDK - qualcosa che affronteremo andando avanti).
Con questo in mente, Oracle:
- Crea binari RI basati solo sulla base di codice OpenJDK.
- Rendere disponibili i binari RI sotto il BCL (la normale licenza Java) per gli implementatori commerciali e GPLv2 (con l'eccezione Classpath) per gli implementatori open-source.
- Continuare a fornire il TCK ai licenziatari commerciali, ma anche aggiornare la licenza OCTLA in modo che copra Java SE 7. Quest'ultimo consente agli implementatori open source l'accesso gratuito al TCK per verificarne l'implementazione ...
La decisione di cui sopra implica un grande sforzo per inserire il 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 evidente che tale sforzo sarà più o meno lo stesso di quanto precedentemente fatto nelle versioni "tradizionali" di Sun / Oracle Java.
Ciò rende solo ragionevole mantenere le basi di codice Open e Oracle JDK il più vicino possibile: in caso contrario, la duplicazione dello sviluppo e le correzioni per rendere entrambi i progetti conformi a TCK potrebbero diventare proibitivamente scoraggianti.
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 ulteriormente la sincronizzazione menzionata, con le versioni di aggiornamento di JDK 7, è meglio dare un'occhiata al progetto Open JDK 8 , lo scopo è descritto in modo molto simile a quello di Open JDK 7:
L'obiettivo di questo progetto è produrre un'implementazione di riferimento open source della piattaforma Java SE 8, che verrà definita da JSR 337 nel processo della comunità Java .
Per lo stesso ragionamento spiegato sopra riguardo all'implementazione di riferimento di JDK 7, è, ancora una volta, nel migliore 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 la propria versione conforme a TCK. È vero anche il contrario, vale a dire quanto più vicini saranno entrambi i progetti ora, tanto meno sarà necessario uno sforzo per rilasciare entrambe le implementazioni Java 8.
Ti è mai capitato di supportare in parallelo due versioni leggermente diverse dello stesso software, rivolte a client diversi? Se sì, probabilmente ricordi il desiderio di tenerli entrambi il più vicino possibile e gli inconvenienti che hai riscontrato quando questi erano fuori sincrono. Con Open e Oracle JDK, è praticamente così, solo su larga scala.
Quasi tutte le correzioni di bug passano direttamente attraverso il progetto OpenJDK e quindi nei distributori JVM a valle (Oracle, Azul, RedHat ecc.).
Un'eccezione è che alcune patch di sicurezza sono state riparate nelle versioni downstream (in particolare Oracle) prima di essere trasferite tranquillamente in OpenJDK. Ciò consente ai fornitori di aggiornare la maggior parte del mondo con la correzione di sicurezza prima di pubblicizzare la vulnerabilità nel progetto open source.
Alcuni venditori scelgono anche di non reinserire le proprie modifiche in OpenJDK. Ad esempio, sia Google che Twitter hanno modificato le versioni di OpenJDK che utilizzano internamente con correzioni di bug e funzionalità che non sono tornate al progetto OpenJDK principale.
HTH