Wyjaśnia to wiele szczegółów na stronie OpenJDK: Pytania i odpowiedzi dotyczące aktualizacji projektu JDK 7
Czy ten projekt będzie stanowił podstawę wydań aktualizacji Oracle JDK 7?
Tak.
Cytat z FOSDEM Joe Darcy'ego posta na blogu na OpenJDK 6 :
W szczególności nie będzie tej samej dychotomii między bazą kodu OpenJDK 7 a bazą kodu aktualizacji 7, jak między OpenJDK 6 a kolejką aktualizacji 6 ...
Według mojego odczytu powyższe zasadniczo oznacza, że łatki i aktualizacje zwykle będą najpierw otwierane w JDK, a następnie, z możliwie najmniejszym opóźnieniem, dostarczane w Oracle JDK.
W przypadku poprawek bezpieczeństwa obraz wydaje się być odwrotny, tzn. Wolałbym, aby najpierw przechodzili do wydań Oracle, a następnie (ponownie z możliwie najmniejszym opóźnieniem) do OpenJDK:
Czy projekt 7 Update otrzyma poprawki bezpieczeństwa od Oracle?
Tak.
Podobnie jak w przypadku OpenJDK 6, poprawki bezpieczeństwa są najpierw traktowane jako poufne i stosowane w lesie prywatnym, zanim zostaną wypchnięte do lasu publicznego w ramach ogólnej zsynchronizowanej publikacji poprawki w pociągach wydania JDK, których dotyczy problem. Ponadto nie przejdą procesu przeglądu kodu publicznego i procesu zatwierdzania wycofania, a odpowiadające im problemy w narzędziu do śledzenia problemów projektu nie będą publicznie widoczne.
Kiedy ten projekt otrzyma poprawki bezpieczeństwa od Oracle?
Harmonogram aktualizacji poprawek krytycznych Oracle Java SE jest publicznie dostępny .
Poprawki bezpieczeństwa dla kodu źródłowego tego projektu zostaną udostępnione w projekcie aktualizacji JDK 7 mniej więcej w tym samym czasie, gdy zostaną wydane w produktach firmy Oracle ...
Aby lepiej zrozumieć powody, dla których wydaje się, że tyle wysiłku włożono w synchronizację Oracle i Open JDK, warto spojrzeć na decyzję Oracle dotyczącą poprzedniego projektu: przejście na OpenJDK jako oficjalną implementację Java SE 7 Reference :
... Oracle i inni członkowie grupy Java SE 7 Expert dopracowują specyfikację Java SE 7 ( JSR 336 ). Jako lider specyfikacji Oracle jest odpowiedzialne za wdrożenie implementacji referencyjnej Java SE 7 ... zamierzamy zapewnić implementację referencyjną opartą całkowicie na kodzie open source OpenJDK i udostępnić ją na licencji GPL open source .
Rolę implementacji referencyjnej (RI) należy używać jako złotego standardu we wszystkich implementacjach Java. Aby implementacja uzyskała certyfikat zgodności z Java SE, implementator musi przejść dużą liczbę testów zgodności - Technology Compatibility Kit (TCK). Ponadto implementacje można porównać do RI jako dodatkową kontrolę zgodności. Zasadniczo, jeśli twoja implementacja została certyfikowana jako taka sama jak RI, to jest kompatybilna z Javą. Aby uzyskać więcej informacji na ten temat, zapoznaj się z często zadawanymi pytaniami dotyczącymi JCP .
Historycznie Sun zawsze używał Sun JDK jako RI i udostępniał go na podstawie licencji na kod binarny (BCL). Było to bardzo wygodne dla Sun, ponieważ oznaczało, że jego implementacja produktu była z definicji kompatybilna. Było to jednak mylące, ponieważ Sun JDK zawierał sporo funkcji, które nie były częścią standardu, takich jak wtyczka Java. Ponadto kontynuowanie tej praktyki utrudniłoby implementatorom oprogramowania typu open source, ponieważ nie byliby w stanie przestudiować i ocenić oficjalnego kodu źródłowego RI. (Kod źródłowy Oracle JDK jest nieco inny niż OpenJDK - coś, o czym będziemy się zajmować, idąc naprzód).
Mając to na uwadze, Oracle:
- Twórz pliki binarne RI tylko na podstawie kodu OpenJDK.
- Udostępnij pliki binarne RI w ramach BCL (normalna licencja Java) dla komercyjnych implementatorów i GPLv2 (z wyjątkiem Classpath) dla implementatorów open source.
- Kontynuuj dostarczanie TCK licencjobiorcom komercyjnym, ale także aktualizuj licencję OCTLA, tak aby obejmowała ona Java SE 7. Ta ostatnia umożliwia implementatorom open source darmowy dostęp do TCK w celu weryfikacji ich implementacji ...
Powyższa decyzja oznacza duży wysiłek włożony w kod Open JDK, aby wydać oficjalnie zweryfikowany, przetestowany, licencjonowany i zgodny kod. Jeśli dodasz, że musi zostać wydany zgodnie z ustalonym harmonogramem publicznym, staje się oczywiste, że taki wysiłek będzie mniej więcej taki sam, jak wcześniej wkładany w „tradycyjne” wydania Sun / Oracle Java.
To sprawia, że rozsądne jest utrzymywanie baz kodu Open JDK i Oracle jak najbliżej: w przeciwnym razie powielanie prac programistycznych i poprawek, aby oba projekty były zgodne z TCK, może stać się zniechęcającym.
Wygląda na to, że decyzja o użyciu Open JDK jako implementacji referencyjnej sprawiła, że w najlepszym interesie Oracle jest utrzymanie JDK jak najbliżej synchronizacji z Open JDK - aż do wydania JDK 7.
Aby zrozumieć, co może zmotywować Oracle do dalszej synchronizacji wspomnianych elementów, dzięki wydaniom aktualizacji JDK 7 lepiej przyjrzeć się projektowi Open JDK 8 , którego cel jest opisany bardzo podobnie do Open JDK 7:
Celem tego projektu jest opracowanie referencyjnej implementacji platformy Java SE 8 o otwartym kodzie źródłowym, która zostanie zdefiniowana przez JSR 337 w procesie społeczności Java .
Z tego samego powodu, co wyjaśniono powyżej w odniesieniu do referencyjnej implementacji JDK 7, ponownie w najlepszym interesie Oracle jest utrzymanie aktualizacji obu JDK w jak największym stopniu zsynchronizowanym.
Im więcej różnic między tymi pakietami JDK, tym trudniej Oracle wydać Java SE 8, ze względu na powielanie wysiłków niezbędnych do dostosowania własnej wersji do TCK. Odwrotna jest również prawda, tzn. Im bliżej będą oba projekty, tym mniej wysiłku będzie wymagać wydanie obu implementacji Java 8.
Czy zdarzyło Ci się kiedykolwiek obsługiwać równolegle dwie nieco różne wersje tego samego oprogramowania, skierowane do różnych klientów? Jeśli tak, prawdopodobnie pamiętasz chęć trzymania ich obu tak blisko, jak to możliwe, oraz niedogodności, których doświadczyłeś, gdy nie były zsynchronizowane. Z pakietami JDK Open i Oracle jest to bardzo podobne, tylko na większą skalę.
Prawie wszystkie poprawki błędów przechodzą bezpośrednio przez projekt OpenJDK, a następnie do dalszych dostawców JVM (Oracle, Azul, RedHat itp.).
Wyjątkiem jest to, że niektóre poprawki bezpieczeństwa są naprawiane w wersjach podrzędnych (w szczególności Oracle) przed cichym przeniesieniem ich z powrotem do OpenJDK. Dzięki temu dostawcy mogą zaktualizować większość świata za pomocą poprawki bezpieczeństwa, zanim opublikują lukę w projekcie open source.
Niektórzy dostawcy decydują się również nie wypychać swoich zmian z powrotem do OpenJDK. Na przykład zarówno Google, jak i Twitter zmodyfikowały wersje OpenJDK, których używają wewnętrznie, z poprawkami błędów i funkcjami, które nie powróciły do głównego projektu OpenJDK.
HTH
źródło