OSGi, Java Modularity และ Jigsaw


95

เมื่อเช้าวานนี้ฉันไม่ทราบว่า OSGi เป็นอย่างไร OSGiเป็นเพียงคำศัพท์ที่ฉันเห็นการครอบตัดซ้ำแล้วซ้ำเล่าและในที่สุดฉันก็เผื่อเวลาไว้สักพัก

ดูเหมือนจะเป็นเรื่องที่น่าสนใจจริงๆดังนั้นฉันจึงขอเริ่มต้นด้วยการระบุ (สำหรับบันทึก) ว่าฉันไม่ได้ต่อต้าน OSGi ในแง่ใด ๆ และนี่ก็ไม่ใช่คำถาม "OSGi-bashing"

ในตอนท้ายของวันดูเหมือนว่า OSGi ได้กล่าวถึงJSR 277บน Java Modularity ซึ่งเป็นที่ยอมรับว่ามีข้อบกพร่องเกี่ยวกับJARข้อกำหนดไฟล์ที่อาจนำไปสู่ความละเอียดของเนมสเปซและปัญหาการโหลดคลาสในบางกรณี OSGi ยังทำสิ่งดีๆอื่น ๆ อีกมากมาย แต่จากสิ่งที่ฉันสามารถตรวจสอบได้นั่นคือสิ่งที่ดึงดูดความสนใจมากที่สุด (หรือหนึ่งในนั้น)

สำหรับฉัน - ในฐานะผู้พัฒนา Java EE ที่ค่อนข้างใหม่ (ไม่กี่ปีนี้) เป็นเรื่องที่น่าเหลือเชื่ออย่างยิ่งที่เราอยู่ในปี 2011 และปัจจุบันอาศัยอยู่ในยุคของ Java 7 และปัญหาการโหลดคลาสเหล่านี้ยังคงมีอยู่ โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมขององค์กรที่เซิร์ฟเวอร์แอปหนึ่งสามารถมี JAR ได้หลายร้อยตัวโดยหลายตัวขึ้นอยู่กับเวอร์ชันที่แตกต่างกันและทั้งหมดทำงานพร้อมกัน (มากหรือน้อย)

คำถามของฉัน:

ในฐานะที่ฉันสนใจใน OSGi และฉันก็อยากจะเริ่มเรียนรู้เกี่ยวกับเรื่องนี้มากที่สุดเพื่อดูว่ามันสามารถนำไปใช้กับโปรเจ็กต์ของฉันได้ที่ไหน / ถ้าฉันไม่มีเวลานั่งลงและเรียนรู้บางสิ่งที่ใหญ่ขนาดนั้น อย่างน้อยก็ตอนนี้

แล้วนักพัฒนาที่ไม่ใช่ OSGi จะทำอย่างไรเมื่อเกิดปัญหาเหล่านี้ขึ้น? อะไรJava (Oracle / อาทิตย์ / JCP) โซลูชั่นมีอยู่ในปัจจุบันถ้ามี? เหตุใด Jigsaw จึงถูกตัดออกจาก J7 ชุมชนแน่ใจแค่ไหนที่ Jigsaw จะถูกนำมาใช้ในปีหน้าใน J8? เป็นไปได้ไหมที่จะรับ Jigsaw สำหรับโครงการของคุณแม้ว่าจะยังไม่ได้เป็นส่วนหนึ่งของแพลตฟอร์ม Java

ฉันเดาว่าสิ่งที่ฉันถามต่อไปนี้เป็นการผสมผสานระหว่างความตื่นตระหนกการวางอุบายและการมองหน้า ในที่สุดตอนนี้ฉันก็เข้าใจแล้วว่า OSGi คืออะไรฉันไม่ "เข้าใจ" ว่าบางสิ่งอย่างเช่น Jigsaw ใช้เวลากว่า 20 ปีกว่าจะบรรลุผลได้อย่างไรแล้วสิ่งนั้นจะตกกระป๋องจากการเปิดตัวได้อย่างไร ดูเหมือนเป็นพื้นฐาน

และในฐานะนักพัฒนาฉันก็อยากรู้เหมือนกันว่าโซลูชันของฉันคืออะไรจึงไม่มี OSGi

นอกจากนี้หมายเหตุ : ฉันรู้ว่านี่ไม่ใช่คำถามประเภท " การเขียนโปรแกรมล้วนๆ " แต่ก่อนที่คุณบางคนจะจมูกงอผิดรูปฉันอยากจะบอก (อีกครั้งสำหรับบันทึก) ว่าฉันจงใจใส่คำถามนี้ ดังนั้น. นั่นเป็นเพราะฉันไม่มีอะไรเลยนอกจากความเคารพอย่างสูงสุดต่อ SOers เพื่อนของฉันและฉันกำลังมองหาคำตอบระดับสถาปัตยกรรมจาก "เทพเจ้าแห่งไอที" ที่ฉันเห็นซุ่มอยู่ที่นี่ทุกวัน

แต่สำหรับพวกคุณที่ยืนยันอย่างแน่นอนว่าคำถาม SO จะได้รับการสนับสนุนด้วยส่วนรหัสบางส่วน:

int x = 9;

(ขอบคุณทุกคนที่สามารถชั่งน้ำหนักใน OSGi / Jigsaw / classloader / namespace / JAR hell stuff!)


Java 9 อยู่ที่นี่เมื่อวานพร้อมกับ Jigsaw น่าอ่าน: จิ๊กซอว์ 10 อันดับแรกและความเข้าใจผิด Java 9 ที่ถูกหักล้าง
David Tonhofer

คำตอบ:


100

ก่อนอื่นให้เข้าใจว่ากรณีการใช้งานหลักของ Jigsaw คือการทำ JRE เอง เป้าหมายรองจะนำเสนอระบบโมดูลที่อาจใช้โดยไลบรารีและแอปพลิเคชัน Java อื่น ๆ

ตำแหน่งของฉันคือบางอย่างเช่น Jigsaw อาจจำเป็นสำหรับ JRE เท่านั้น แต่จะสร้างปัญหามากกว่าที่จะแก้ปัญหาได้หากใช้โดยไลบรารีหรือแอป Java อื่น ๆ

JRE เป็นกรณีที่ยากและพิเศษมาก อายุมากกว่า 12 ปีและเป็นเรื่องยุ่งเหยิงที่น่ากลัวเต็มไปด้วยวงจรการพึ่งพาและการพึ่งพาที่ไร้สาระ ในขณะเดียวกันก็ถูกใช้โดยนักพัฒนาประมาณ9 ล้านคนและอาจเป็นระบบที่รันอยู่หลายพันล้านระบบ ดังนั้นคุณจะไม่สามารถ refactor JRE ได้อย่างแน่นอนหากการปรับโครงสร้างใหม่นั้นสร้างการเปลี่ยนแปลงที่ไม่สมบูรณ์

OSGi เป็นระบบโมดูลที่ช่วยคุณ (หรือบังคับให้คุณ) สร้างซอฟต์แวร์ที่เป็นโมดูล คุณไม่สามารถโรย modularity ไว้ด้านบนของ codebase ที่ไม่ใช่ modular ที่มีอยู่ได้ การสร้างโค้ดเบสที่ไม่ใช่แบบโมดูลาร์ให้เป็นโมดูลาร์นั้นจำเป็นต้องมีการปรับโครงสร้างใหม่อย่างหลีกเลี่ยงไม่ได้: การย้ายคลาสไปยังแพ็กเกจที่ถูกต้อง, การแทนที่อินสแตนซ์โดยตรงด้วยการใช้บริการแยกส่วน

ทำให้ยากที่จะนำ OSGi ไปใช้กับ JRE codebase โดยตรง แต่เรายังคงมีข้อกำหนดในการแยก JRE ออกเป็นชิ้น ๆ หรือ "โมดูล" เพื่อให้สามารถส่งมอบ JRE เวอร์ชันที่ตัดลงได้

ฉันจึงถือว่าจิ๊กซอว์เป็น " มาตรการที่รุนแรง " เพื่อให้โค้ด JRE คงอยู่ในขณะที่แยกมัน มันไม่ได้ช่วยให้โค้ดกลายเป็นโมดูลาร์มากขึ้นและฉันเชื่อว่ามันจะเพิ่มการบำรุงรักษาที่จำเป็นในการพัฒนาไลบรารีหรือแอพพลิเคชั่นที่ใช้งานได้จริง

สุดท้าย: OSGi มีอยู่ในขณะที่ Jigsaw ยังไม่มีอยู่และอาจไม่มีอยู่จริง ชุมชน OSGi มีประสบการณ์ 12 ปีในการพัฒนาแอปพลิเคชันแบบแยกส่วน หากคุณสนใจอย่างจริงจังในการพัฒนาแอพพลิเคชั่นแบบแยกส่วน OSGi เป็นเกมเดียวในเมือง


นี่คุณด้วยเหรอ? slideshare.net/mfrancis/…เนื้อหาเกือบเหมือนกัน
Jin Kwon

นอกจากนี้ยังมีโมดูล JBoss: docs.jboss.org/author/display/MODULES/Introductionนอกจากนี้ยังใช้โดย Ceylon (ceylonlang.org) ดูหัวข้อนี้ในฟอรัมผู้ใช้ Ceylon: groups.google.com/forum/?hl=de#!topic/ceylon-users/RmDskLDNkug
OlliP

ข้อความสุดท้าย: "หากคุณสนใจอย่างจริงจังในการพัฒนาแอปพลิเคชันแบบแยกส่วน OSGi เป็นเกมเดียวในเมือง"ยังคงมีอยู่หรือไม่?
Adam Arold

1
@AdamArold ฉันเชื่ออย่างนั้น Jigsaw ยังไม่มีอยู่ใน Java เวอร์ชันใด ๆ JSR 376 (Java Platform Module System) ยังคงสร้างกลุ่มผู้เชี่ยวชาญและยังไม่ได้เริ่มในร่างแรก Java 9 ไม่ครบกำหนดมานานกว่าหนึ่งปีและแม้ว่าจะปล่อยออกมาก็ไม่รับประกันว่าจะมีโมดูลาร์ (มันหลุดจาก Java 7 จากนั้นมาจาก Java 8 และอาจลื่นอีกครั้งได้อย่างง่ายดาย) สุดท้ายข้อกำหนดที่เผยแพร่สำหรับ JSR376ระบุว่าจำเป็นต้องมีการทำงานร่วมกันของ OSGi ... ดังนั้นการนำ OSGi มาใช้จึงยังคงเป็นทางเลือกที่ปลอดภัยและวันนี้เป็นทางเลือกเดียวที่ใช้ได้จริง
Neil Bartlett

2
@AdamArold เอาล่ะเป็นคำถามที่แตกต่างออกไป! คุณอาจพูดได้ว่า OSGi เป็นสถาปัตยกรรมไมโครเซอร์วิส แต่ฉันรู้ว่าคุณกำลังพูดอะไร สำหรับฉันความคิดในการสร้างแบบจำลองบริการทุกอย่างเป็นกระบวนการเป็นปัญหาที่ซับซ้อนกว่ามากในแง่ของการจัดการและความปลอดภัยและค่าใช้จ่ายในการติดต่อสื่อสาร OSGi นั้นง่ายและเร็วกว่า ต้องบอกว่ามันง่ายมากที่จะใช้ OSGi Remote Services เพื่อเปลี่ยนบริการเข้าและออกจากอุปสรรคของกระบวนการดังนั้นฉันเชื่อว่านี่เป็นทางเลือกที่ดีสำหรับเทคโนโลยีการใช้งานสำหรับไมโครเซอร์วิส
Neil Bartlett

21

มันง่ายมากถ้าคุณต้องการทำการพัฒนาตามองค์ประกอบจริงใน Java วันนี้ OSGi เป็นเกมเดียวในเมือง

ในความคิดของฉัน Jigsaw เป็นการรวมกันของการประนีประนอมของสิ่งที่ทำได้ใน JDK และความสัมพันธ์ที่ไม่ดีก่อนหน้านี้ระหว่าง SUN และพวก OSGi บางทีมันอาจจะมาพร้อมกับ Java 8 แต่เราต้องรอดู

OSGi ไม่ใช่ยาครอบจักรวาลหากคุณทำงานในสถานที่ตั้งขององค์กรโดยทั่วไปและคุณจะต้องทำความคุ้นเคยกับวิธีการทำงานของการโหลดคลาสเนื่องจากไลบรารีที่รู้จักกันดีจำนวนมาก (มองไปที่คุณไฮเบอร์เนต) ตั้งสมมติฐานเกี่ยวกับการมองเห็นชั้นเรียนที่ไม่ถูกต้องอีกต่อไป ภายใน OSGi

ฉันชอบ OSGi แต่ฉันจะไม่ลองดัดแปลงเป็นระบบที่มีอยู่ ฉันยังชั่งน้ำหนักข้อดีข้อเสียในแง่ของการพัฒนากรีนฟิลด์ - ฉันขอแนะนำให้ดูผลิตภัณฑ์ Apache หรือ Eclipse ที่ทำให้ OSGi ง่ายขึ้นและไม่ต้องทำเองทั้งหมด

หากคุณไม่ได้ทำ OSGi แสดงว่าคุณโชคไม่ดีหากคุณได้พบกับระบบที่มีการพึ่งพาไลบรารีเดียวกันเวอร์ชันต่างๆสิ่งที่คุณทำได้คือพยายามหลีกเลี่ยงปัญหาแม้ว่าจะต้องใช้ a หลายเวอร์ชัน ห้องสมุดดูเหมือนเป็นสถาปัตยกรรม 'กลิ่น' สำหรับฉัน


ใช่ฉันคิดว่ามี 'เลือดที่ไม่ดี' มากมายระหว่าง Sun และ OSGi Alliance ฉันนึกไม่ถึงว่า Oracle จะปล่อยให้สิ่งต่างๆหลุดออกจากการควบคุมของพวกเขา คุณกำลังบอกฉันจริงๆว่าไม่มีแผนจะแก้ไขอย่างแท้จริง (ไม่ใช่แฮ็ค) สิ่งนรกนี้ในเร็ว ๆ นี้ ที่พัดใจฉัน!
IAmYourFaja

6
@ มาร่าไม่ยุติธรรมจริงๆที่จะบอกว่ามีเลือดไม่ดี อย่างไรก็ตามซันเป็นหนึ่งในผู้ร่วมสร้าง OSGi เมื่อ 12 ปีก่อน (JSR 8) Sun ยังเข้าร่วม OSGi Alliance ในฐานะสมาชิกเต็มรูปแบบประมาณหนึ่งปีก่อนการซื้อกิจการ Oracle พวกเขายังพัฒนาซอฟต์แวร์จำนวนมากที่อยู่เหนือ OSGi, pre-Oracle ตัวอย่างที่ชัดเจนที่สุดคือ Glassfish อย่างไรก็ตามเป็นเรื่องยุติธรรมที่จะกล่าวได้ว่ามีความขัดแย้งระหว่างบุคคลบางคนที่ Sun / Oracle และ OSGi
Neil Bartlett

15

ฉันชอบที่คุณใช้วลี "กรณีมุม" เพื่ออธิบายสถานการณ์ปัจจุบัน

มีข้อบกพร่องเกี่ยวกับข้อกำหนดไฟล์ JAR ที่อาจนำไปสู่ความละเอียดของเนมสเปซและปัญหาการโหลดคลาสในบางกรณี

อย่างไรก็ตามตั้งแต่หลายปีที่ผ่านมาฉันสนใจในเครื่องมือและเทคนิคที่สนับสนุนการสร้างและบังคับใช้โค้ดที่สะอาดกว่าแยกออกจากกันมากขึ้นสอดคล้องกันและดูแลรักษาได้มากกว่าสิ่งที่อาจเป็นผลลัพธ์หากไม่มีพวกเขา Test Driven Design และ Junit เป็นการผสมผสานกันอย่างลงตัว

หลังจากใช้เวลาสองสามเดือนในการย้ายส่วนสำคัญของฐานรหัสของเราไปยัง OSGi ฉันจะบอกว่า OSGi เป็นเครื่องมือที่ดีกว่าในเรื่องนี้ และนั่นเป็นเหตุผลที่เพียงพอที่จะย้ายไป OSGi ในระยะยาวจะช่วยให้คุณประหยัดเงินได้มาก

และเป็นโบนัสจะทำให้คุณมีโอกาสทำสิ่งดีๆมากมาย ลองนึกภาพในระหว่างการสาธิตการอัปเกรดโมดูลการตรวจสอบสิทธิ์อย่างราบรื่นโดยไม่มีการสูญเสียปริมาณการใช้งานเพื่อรองรับ OAuth ...

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.