Câu trả lời:
Điều này được giải thích chi tiết tại trang OpenJDK: Hỏi & Đáp về Đề xuất Dự án Cập nhật JDK 7
Dự án này sẽ làm cơ sở cho các bản phát hành Cập nhật Oracle JDK 7?
Đúng.
Để trích dẫn từ bài đăng trên blog FOSDEM của Joe Darc trên OpenJDK 6 :
Đặc biệt, sẽ không có sự phân đôi giống nhau giữa cơ sở mã OpenJDK 7 và cơ sở mã cập nhật 7 như giữa OpenJDK 6 và tàu cập nhật 6 ...
Theo tôi đọc, về cơ bản có nghĩa là các bản vá và cập nhật thường sẽ đi trước để mở JDK và sau đó, với độ trễ nhỏ nhất có thể, được gửi trong Oracle JDK.
Đối với các bản vá bảo mật, hình ảnh dường như ngược lại, tức là tôi mong muốn chúng đi trước các bản phát hành của Oracle và sau đó (một lần nữa, với độ trễ nhỏ nhất có thể) cho OpenJDK:
Dự án cập nhật 7 sẽ nhận được các bản sửa lỗi bảo mật từ Oracle?
Đúng.
Như với OpenJDK 6, các bản sửa lỗi bảo mật trước tiên được giữ bí mật và được áp dụng cho một khu rừng tư nhân trước khi được đẩy vào rừng công cộng như một phần của ấn phẩm được đồng bộ hóa chung của bản sửa lỗi cho các tàu phát hành JDK bị ảnh hưởng. Ngoài ra, họ sẽ không trải qua quá trình xem xét và phê duyệt mã công khai, và các vấn đề tương ứng của họ trong trình theo dõi vấn đề của Dự án sẽ không được hiển thị công khai.
Khi nào Dự án này sẽ nhận được bản sửa lỗi bảo mật từ Oracle?
Lịch trình cho Oracle Java SE Critical patch cập nhật công khai có sẵn .
Các bản sửa lỗi bảo mật cho mã nguồn của Dự án này sẽ được cung cấp trong Dự án cập nhật JDK 7 cùng lúc với chúng được phát hành trong các sản phẩm từ Oracle ...
Để hiểu rõ hơn về lý do tại sao dường như có rất nhiều nỗ lực để giữ cho Oracle và Open JDK đồng bộ hóa, nên xem xét quyết định của Oracle về dự án trước đó: Chuyển sang OpenJDK làm Triển khai tham chiếu Java SE 7 chính thức :
... Oracle và các thành viên khác trong Nhóm chuyên gia Java SE 7 đã và đang hoàn thiện các đặc điểm kỹ thuật của Java SE 7 ( JSR 336 ). Với vai trò là người lãnh đạo đặc tả, Oracle chịu trách nhiệm cung cấp Triển khai tham chiếu Java SE 7 ... chúng tôi sẽ cung cấp một Triển khai tham chiếu hoàn toàn dựa trên mã nguồn mở OpenJDK và cung cấp nó theo giấy phép nguồn mở GPL .
Vai trò của Triển khai tham chiếu (RI) sẽ được sử dụng làm tiêu chuẩn vàng cho tất cả các triển khai Java. Để có một triển khai được chứng nhận là tương thích Java SE, người triển khai phải vượt qua một số lượng lớn các thử nghiệm tương thích - Bộ tương thích công nghệ (TCK). Hơn nữa, việc triển khai có thể được so sánh với RI như là một kiểm tra bổ sung về tính tương thích. Về cơ bản, nếu việc triển khai của bạn đã được chứng nhận có hành vi tương tự như RI thì nó tương thích với Java. Để biết thêm thông tin về chủ đề này, hãy tham khảo Câu hỏi thường gặp của JCP .
Trong lịch sử, Sun luôn sử dụng Sun JDK làm RI và cung cấp nó theo Giấy phép Mã nhị phân (BCL). Điều này rất thuận tiện cho Sun vì nó có nghĩa là việc triển khai sản phẩm của nó tương thích theo định nghĩa. Tuy nhiên, nó cũng gây nhầm lẫn vì Sun JDK chứa khá nhiều tính năng không phải là một phần của tiêu chuẩn, chẳng hạn như Plugin Java. Ngoài ra, việc tiếp tục thực hành này sẽ gây khó khăn cho những người triển khai nguồn mở vì họ không thể nghiên cứu và đánh giá mã nguồn RI chính thức. (Mã nguồn cho Oracle JDK hơi khác so với OpenJDK - một cái gì đó chúng tôi sẽ giải quyết trong tương lai).
Với ý nghĩ đó, Oracle sẽ:
- Tạo nhị phân RI chỉ dựa trên cơ sở mã OpenJDK.
- Cung cấp các tệp nhị phân RI theo BCL (giấy phép Java thông thường) cho người triển khai thương mại và GPLv2 (với ngoại lệ Classpath) cho người triển khai nguồn mở.
- Tiếp tục cung cấp TCK cho những người được cấp phép thương mại, nhưng cũng cập nhật giấy phép OCTLA để nó bao gồm Java SE 7. Cái sau cho phép những người triển khai nguồn mở truy cập miễn phí vào TCK để xác minh việc triển khai của họ ...
Quyết định trên có nghĩa là rất nhiều nỗ lực để đưa vào mã JDK mở, để phát hành mã được xác minh, thử nghiệm, cấp phép và tuân thủ chính thức. Nếu bạn thêm rằng nó phải được phát hành theo lịch trình công khai đã thỏa thuận, thì rõ ràng là một nỗ lực như vậy sẽ giống như trước đây đã được đưa vào các bản phát hành Java / Sun / Oracle truyền thống.
Điều này chỉ hợp lý khi giữ các cơ sở mã JDK của Open và Oracle càng gần càng tốt: nếu không, việc sao chép phát triển và sửa lỗi để làm cho cả hai dự án tuân thủ TCK có thể trở nên khó khăn.
Có vẻ như quyết định sử dụng Open JDK làm Triển khai tham chiếu đã khiến Oracle quan tâm nhất đến việc giữ JDK của họ càng gần càng tốt đồng bộ với Open JDK - cho đến khi phát hành JDK 7.
Để hiểu điều gì có thể thúc đẩy Oracle tiếp tục đồng bộ hóa được đề cập, với các bản phát hành cập nhật JDK 7, tốt hơn hết bạn nên xem dự án Open JDK 8 , mục đích được mô tả khá giống với Open JDK 7:
Mục tiêu của Dự án này là tạo ra một triển khai tham chiếu nguồn mở của Nền tảng Java SE 8, được xác định bởi JSR 337 trong Quy trình cộng đồng Java .
Với lý do tương tự như đã được giải thích ở trên liên quan đến việc triển khai tham chiếu của JDK 7, một lần nữa, vì lợi ích tốt nhất của Oracle là giữ cho các bản cập nhật của cả hai JDK càng đồng bộ càng tốt.
Càng có nhiều sự khác biệt giữa các JDK này, Oracle càng khó phát hành Java SE 8, do sự trùng lặp các nỗ lực cần thiết để đưa bản phát hành của riêng mình tuân thủ TCK. Điều ngược lại cũng đúng, tức là cả hai dự án sẽ càng gần hơn, sẽ cần ít nỗ lực hơn để phát hành cả hai triển khai Java 8.
Bạn đã bao giờ tình cờ hỗ trợ song song hai phiên bản hơi khác nhau của cùng một phần mềm, nhắm vào các khách hàng khác nhau chưa? Nếu có, bạn có thể nhớ mong muốn giữ cả hai càng gần càng tốt và những bất tiện bạn gặp phải khi những điều này không đồng bộ. Với Open và Oracle JDK, nó khá giống như vậy, chỉ ở quy mô lớn hơn.
Hầu như tất cả các bản sửa lỗi đều đi trực tiếp qua dự án OpenJDK và sau đó vào các nhà cung cấp JVM hạ nguồn (Oracle, Azul, RedHat, v.v.).
Một ngoại lệ là một số bản vá bảo mật được sửa trong các phiên bản hạ nguồn (đặc biệt là Oracle) trước khi lặng lẽ chuyển nó trở lại OpenJDK. Điều này cho phép các nhà cung cấp nâng cấp hầu hết thế giới với bản sửa lỗi bảo mật trước khi công khai lỗ hổng trong dự án nguồn mở.
Một số nhà cung cấp cũng chọn không đẩy các thay đổi của họ trở lại OpenJDK. Ví dụ, cả Google và Twitter đều đã sửa đổi các phiên bản OpenJDK mà họ sử dụng nội bộ với các sửa lỗi và các tính năng chưa quay trở lại trong dự án OpenJDK chính.
HTH