การบำรุงรักษา OpenJDK ทำงานอย่างไรในทางปฏิบัติ

โดยเฉพาะฉันต้องการทำความเข้าใจความแตกต่างระหว่าง JDK ของ Oracle และ OpenJDK ในแง่ของการแก้ไขข้อบกพร่องและโปรแกรมแก้ไขอื่น ๆ

สาขาใดได้รับการแก้ไขเป็นอันดับแรกและ Oracle มีนิสัยชอบทำแพตช์ที่ไม่เคยทำให้ OpenJDK

นี่คือคำอธิบายโดยละเอียดในหน้า OpenJDK: คำถามและคำตอบโครงการปรับปรุง JDK 7

โครงการนี้จะใช้เป็นพื้นฐานสำหรับการปรับปรุง Oracle JDK 7 หรือไม่

ใช่.

หากต้องการอ้างอิงจากโพสต์บล็อกของ Joe Darcy's FOSDEM ใน OpenJDK 6 :

โดยเฉพาะอย่างยิ่งจะไม่มีขั้วต่อเดียวกันระหว่างฐานรหัส OpenJDK 7 และฐานรหัสการอัพเดท 7 เนื่องจากมีอยู่ระหว่าง OpenJDK 6 และขบวนรถไฟปรับปรุง 6 ...

จากการอ่านของฉันข้างต้นนั้นหมายถึงว่าโดยทั่วไปโปรแกรมแก้ไขและโปรแกรมปรับปรุงจะไปที่ Open JDK เป็นอันดับแรกและจากนั้นจะมีการจัดส่งล่าช้าเล็กน้อยใน Oracle JDK

สำหรับแพตช์ความปลอดภัยดูเหมือนว่าภาพจะตรงกันข้ามเช่นฉันคาดหวังว่าพวกเขาจะไปเปิดตัว Oracle ก่อนแล้วจึงค่อยเปิดใหม่อีกครั้ง (อีกครั้งด้วยความล่าช้าเล็กน้อย)

7 Update Project จะได้รับการแก้ไขด้านความปลอดภัยจาก Oracle หรือไม่

ใช่.

เช่นเดียวกับ OpenJDK 6 การแก้ไขความปลอดภัยจะถูกเก็บเป็นความลับและนำไปใช้กับไพรเวตฟอเรสต์ก่อนที่จะถูกส่งไปยังฟอเรสต์สาธารณะโดยเป็นส่วนหนึ่งของการเผยแพร่การซิงโครไนซ์ทั่วไป นอกจากนี้พวกเขาจะไม่ผ่านการตรวจสอบรหัสสาธารณะและกระบวนการอนุมัติการย้อนกลับและปัญหาที่เกี่ยวข้องในการติดตามปัญหาของโครงการจะไม่ปรากฏต่อสาธารณะ

โครงการนี้จะได้รับการแก้ไขด้านความปลอดภัยจาก Oracle เมื่อใด

ตารางเวลาสำหรับ Java SE อัพเดทออราเคิล Critical Patch เป็นสาธารณชนใช้ได้

การแก้ไขความปลอดภัยสำหรับซอร์สโค้ดของโครงการนี้จะมีให้ในโครงการปรับปรุง JDK 7 ในเวลาเดียวกับที่พวกเขาวางจำหน่ายในผลิตภัณฑ์จาก Oracle ...

เพื่อทำความเข้าใจสาเหตุที่ทำให้มีความพยายามอย่างมากในการทำให้ Oracle และ Open JDKs สอดคล้องกันจึงควรพิจารณาการตัดสินใจของ Oracle ในโครงการก่อนหน้านี้: การย้ายไปยัง OpenJDK เป็นการดำเนินการอ้างอิง Java SE 7 อย่างเป็นทางการ :

... Oracle และสมาชิกคนอื่น ๆ ของกลุ่มผู้เชี่ยวชาญ Java SE 7 ได้ทำการปรับแต่งให้เข้ากับข้อมูลจำเพาะ Java SE 7 ( JSR 336 ) ในบทบาทของการเป็นผู้นำด้านข้อกำหนด Oracle มีหน้าที่รับผิดชอบในการส่งมอบการดำเนินการอ้างอิง Java SE 7 ... เราจะให้การใช้งานอ้างอิงที่อิงกับ OpenJDK รหัสโอเพนซอร์สทั้งหมดและทำให้สามารถใช้งานได้ภายใต้ใบอนุญาตโอเพ่นซอร์ส GPL .

บทบาทของ Reference Implementation (RI) จะถูกใช้เป็นมาตรฐานทองคำสำหรับการใช้งาน Java ทั้งหมด เพื่อให้การใช้งานได้รับการรับรองว่ารองรับ Java SE ผู้ดำเนินการจะต้องผ่านการทดสอบความเข้ากันได้จำนวนมาก - Technology Compatibility Kit (TCK) นอกจากนี้การใช้งานอาจเปรียบเทียบกับ RI เป็นการตรวจสอบความเข้ากันได้เพิ่มเติม โดยทั่วไปหากการใช้งานของคุณได้รับการรับรองว่ามีพฤติกรรมเช่นเดียวกับ RI ก็จะเข้ากันได้กับ Java สำหรับข้อมูลเพิ่มเติมเกี่ยวกับหัวข้อนี้ปรึกษาJCP คำถามที่พบบ่อย

ในอดีตซันใช้ Sun JDK เป็น RI และทำให้ใช้ได้ภายใต้ Binary Code License (BCL) นี่เป็นสิ่งที่สะดวกมากสำหรับซันเพราะมันหมายความว่าการติดตั้งใช้งานผลิตภัณฑ์นั้นเข้ากันได้กับคำจำกัดความ อย่างไรก็ตามมันก็สับสนเนื่องจาก Sun JDK มีคุณสมบัติบางอย่างที่ไม่ได้เป็นส่วนหนึ่งของมาตรฐานเช่นปลั๊กอิน Java นอกจากนี้การฝึกฝนนี้ต่อไปจะทำให้สิ่งต่าง ๆ ยากขึ้นสำหรับผู้ใช้งานโอเพ่นซอร์สเนื่องจากพวกเขาไม่สามารถศึกษาและประเมินซอร์สโค้ด RI อย่างเป็นทางการได้ (ซอร์สโค้ดสำหรับ Oracle JDK นั้นแตกต่างจาก OpenJDK เล็กน้อยซึ่งเป็นสิ่งที่เราจะดำเนินการต่อไป)

เมื่อคำนึงถึงสิ่งนี้ Oracle จะ:

• สร้างไบนารี RI ตามฐานรหัส OpenJDK เท่านั้น
• ทำให้ไบนารี RI พร้อมใช้งานภายใต้ BCL (สิทธิ์การใช้งาน Java ปกติ) สำหรับผู้วางระบบเชิงพาณิชย์และ GPLv2 (พร้อมข้อยกเว้น Classpath) สำหรับผู้พัฒนาโอเพ่นซอร์ส
• ดำเนินการต่อเพื่อให้ TCK แก่ผู้ได้รับใบอนุญาตการค้า แต่ยังอัปเดตใบอนุญาตOCTLAเพื่อให้ครอบคลุม Java SE 7 หลังช่วยให้ผู้ใช้โอเพ่นซอร์สฟรีเข้าถึง TCK เพื่อตรวจสอบการใช้งานของพวกเขา ...

การตัดสินใจข้างต้นหมายถึงความพยายามอย่างมากในการใส่รหัส Open JDK เพื่อปล่อยรหัสที่ได้รับการตรวจสอบอย่างเป็นทางการ หากคุณเพิ่มว่าจะต้องมีการเปิดตัวตามกำหนดเวลาสาธารณะที่ตกลงกันไว้จะเห็นได้ชัดว่าความพยายามดังกล่าวจะเหมือนกับก่อนหน้านี้ที่วางไว้ในรุ่น "ดั้งเดิม" ของ Sun / Oracle Java

สิ่งนี้ทำให้มีเหตุผลเท่านั้นที่จะทำให้รหัสฐาน Open และ Oracle JDK ใกล้เคียงที่สุดเท่าที่จะเป็นไปได้มิฉะนั้นการทำซ้ำการพัฒนาและการแก้ไขเพื่อให้ทั้งสองโครงการที่สอดคล้องกับ TCK อาจกลายเป็นข้อห้ามที่น่าสงสัย

ดูเหมือนว่าการตัดสินใจที่จะใช้ Open JDK ในฐานะการใช้งานอ้างอิงทำให้เป็นประโยชน์สูงสุดของ Oracle ในการรักษา JDK ของตนให้ใกล้เคียงที่สุดเท่าที่จะเป็นไปได้ในการซิงค์กับ Open JDK - จนถึงการเปิดตัว JDK 7

เพื่อให้เข้าใจสิ่งที่อาจเป็นแรงจูงใจให้ออราเคิลทำการซิงค์ที่กล่าวถึงต่อไปด้วยการเปิดตัวการปรับปรุง JDK 7 เราน่าจะพิจารณาโครงการOpen JDK 8ซึ่งวัตถุประสงค์จะอธิบายค่อนข้างคล้ายกับ Open JDK 7:

เป้าหมายของโครงการนี้คือการผลิตดำเนินการอ้างอิงเปิดแหล่งที่มาของ 8 แพลตฟอร์ม Java SE จะถูกกำหนดโดยJSR 337ในกระบวนการ Java Community

ด้วยเหตุผลเดียวกับที่อธิบายไว้ข้างต้นเกี่ยวกับการใช้งานอ้างอิงของ JDK 7 เป็นอีกครั้งเพื่อประโยชน์สูงสุดของ Oracle ในการอัปเดต JDK ทั้งสองให้ตรงกันมากที่สุดเท่าที่จะทำได้

ความแตกต่างที่มากขึ้นระหว่าง JDK เหล่านี้ตอนนี้ยากกว่าที่ Oracle จะปล่อย Java SE 8 เนื่องจากการทำซ้ำของความพยายามที่จำเป็นเพื่อนำการปล่อยของตนเองไปปฏิบัติตาม TCK สิ่งที่ตรงกันข้ามก็เป็นจริงเช่นกันว่าทั้งสองโครงการใกล้เข้ามามากขึ้นเท่าไรความพยายามที่น้อยกว่านั้นจะต้องมีการเปิดตัว Java 8 ทั้งสองตัว

คุณเคยให้การสนับสนุนในซอฟต์แวร์รุ่นเดียวกันสองรุ่นที่ต่างกันเล็กน้อยโดยมีกลุ่มลูกค้าเป้าหมายต่างกันหรือไม่? ถ้าใช่คุณอาจจำความต้องการที่จะรักษาทั้งคู่ให้ใกล้เคียงที่สุดและความไม่สะดวกที่คุณพบเมื่อสิ่งเหล่านี้ไม่ซิงค์กัน ด้วย Open และ Oracle JDKs มันก็เป็นเช่นนั้นในระดับที่ใหญ่กว่าเท่านั้น

การแก้ไขข้อบกพร่องเกือบทั้งหมดผ่านโครงการ OpenJDK โดยตรงจากนั้นไปยังผู้ขาย JVM แบบดาวน์สตรีม (Oracle, Azul, RedHat และอื่น ๆ )

ข้อยกเว้นคือแพตช์รักษาความปลอดภัยบางอย่างได้รับการแก้ไขในเวอร์ชันดาวน์สตรีม (โดยเฉพาะ Oracle) ก่อนที่จะถูกย้ายไปยัง OpenJDK อย่างเงียบ ๆ สิ่งนี้ทำให้ผู้ค้าสามารถอัพเกรดโลกส่วนใหญ่ด้วยการแก้ไขความปลอดภัยก่อนที่จะเผยแพร่ช่องโหว่ในโครงการโอเพ่นซอร์ส

ผู้ค้าบางรายเลือกที่จะไม่ผลักดันการเปลี่ยนแปลงกลับสู่ OpenJDK ตัวอย่างเช่นทั้ง Google และ Twitter ได้แก้ไข OpenJDK เวอร์ชันที่พวกเขาใช้ภายในด้วยการแก้ไขข้อบกพร่องและคุณสมบัติที่ไม่ได้กลับเข้าไปในโครงการ OpenJDK หลัก

HTH