जावा 9 में पैकेज और मॉड्यूल अलग-अलग अवधारणाएं क्यों हैं?

Question

जावा 9 में पैकेज के अलावा मॉड्यूल होंगे। आमतौर पर भाषाओं में एक या दूसरी होती है। और अधिकांश प्रोग्रामर दो शब्दों को समानार्थक मानते हैं। मॉड्यूल पैकेज के शीर्ष पर बनाए जाते हैं, उन्हें आदिम मानते हैं। समग्र पैटर्न आदिम और कंपोजिट को समान रूप से व्यवहार करने का सुझाव देता है। अन्यथा बुरे काम होंगे। उदाहरण के लिए, प्रोजेक्ट वल्लाह को देखें, जहां वे आदिम (मूल्य) और संदर्भ प्रकारों के लिए सामान्य सुपरटेप को फिर से बनाने की कोशिश करते हैं।

क्या मॉड्यूल और पैकेज शब्दार्थ रूप से अलग-अलग धारणाओं का प्रतिनिधित्व करते हैं? मतलब किसी भी भाषा (चिंताओं को अलग करना) के लिए दोनों का होना समझदारी है । या जावा को पिछड़ी अनुकूलता के लिए श्रद्धांजलि के रूप में दोनों होना चाहिए?

मौजूदा अवधारणा को बढ़ाने के बजाय नई अवधारणा क्यों पेश करें?

---

JSR 376 : "जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम" प्रोजेक्ट आरा के भीतर लागू किया गया ।

SOTMS के अनुसार

एक मॉड्यूल कोड और डेटा का एक नामित, आत्म-वर्णन संग्रह है। इसका कोड संकुल के एक प्रकार के रूप में आयोजित किया जाता है, अर्थात, जावा वर्ग और इंटरफेस; इसके डेटा में संसाधन और अन्य प्रकार की स्थिर जानकारी शामिल है।

JLS ध्यान से परिभाषित करने से बचता है कि एक पैकेज क्या है । से विकिपीडिया :

जावा पैकेज, जावा कक्षाओं को मॉड्यूल में मॉड्यूल के समान नामस्थानों में व्यवस्थित करने के लिए एक तकनीक है, जो जावा में मॉड्यूलर प्रोग्रामिंग प्रदान करता है।

मुझे पता है कि विकिपीडिया को उद्धृत करना एक बुरा व्यवहार है, लेकिन यह आम समझ को दर्शाता है। मॉड्यूलर प्रोग्रामिंग पर प्रविष्टि से :

शब्द पैकेज का उपयोग कभी-कभी मॉड्यूल (डार्ट, गो, या जावा में) के बजाय किया जाता है । अन्य कार्यान्वयन में, यह एक अलग अवधारणा है; पायथन में एक पैकेज मॉड्यूल का एक संग्रह है, जबकि आगामी जावा 9 में नए मॉड्यूल अवधारणा (बढ़ाया पहुंच नियंत्रण के साथ पैकेजों का एक संग्रह) की शुरूआत की योजना बनाई गई है।

Comments

मुझे लगता है कि आप यहाँ एक साथ बहुत सारे प्रश्न पूछ रहे हैं? 1) क्या मॉड्यूल और पैकेज एक ही अर्थ विचार हैं? 2) (यदि 1 नहीं), तो jigsaw-स्टाइल मॉड्यूल सिर्फ पैकेज पर तकनीकी सुधार हैं? 3) (यदि 1 नहीं और 2 है), तो जावा केवल (या प्रतीत होता है) दोनों अवधारणाओं को पिछड़ी संगतता के लिए रखता है । इन सवालों में से कुछ जवाब देने योग्य हैं, कुछ मुख्य रूप से राय-उन्मुख हैं। मुझे लगता है कि मांगी गई स्पष्टीकरण को सरल बनाने वाला एक संपादन यहां क्रम में है।

— Tersosauros

@Tersosauros को आपने "कुछ" प्रश्नों को ऑफ़-टॉपिक के रूप में वर्गीकृत किया है, लेकिन यह लेबल नहीं किया कि कौन सा है। मैं इसे केवल एक प्रश्न (1) के रूप में देखता हूं। अन्य स्वचालित रूप से हल हो जाएंगे। जावा के लिए पिछड़ी संगतता कोई सवाल नहीं है। इसलिए या तो जावा ने पैच डिज़ाइन डिज़ाइन की खामियों के लिए मॉड्यूल पेश किए या दो धारणाएँ वास्तव में अलग चिंताएँ हैं। और नामकरण खराब नामकरण के कारण है।

— user2418306

मैं प्रश्न को और स्पष्ट करना चाहता हूं। लेकिन मुझे यह समझने की जरूरत है कि आपको कौन सा हिस्सा अचूक लगता है। जब मुझे लगता है कि केवल एक हिस्सा है।

— user2418306

आह, मैं भ्रम को समझता हूं। मुझे लगता है कि सवाल # 1 है जवाबदेह (है कि इसका जवाब किया जा रहा है "हाँ, लेकिन कोई" - जो है, जहां # 3 में आता है)। मैं # 3 के बारे में सहमत हूं, जाहिर है कि जावा उस भाषा को बदलने के बारे में नहीं है जो भाषा का कीवर्ड packageहै / करता है / मतलब है, और न ही वे जेआरई में बदलाव करने जा रहे हैं (चलो, बहुत भयानक है) क्लासपैथ सिस्टम (एस)। प्रश्न # 2 मैं महसूस है मुख्य रूप से राय उन्मुख (यह जवाबदेह है, लेकिन मेरा उत्तर और किसी और के अलग हो सकता है और न ही हम में से जरूरी गलत होगा)।

— Tersosauros

एक स्पष्ट सवाल सामने रखने की कोशिश करें, फिर सहायक सामग्री की आपूर्ति करें।

— जे एलस्टन

Answer 1

अवधारणा एक मॉड्यूल की है कि अवधारणा के इन्स्टेन्शियशन से अलग है।

जावा में हमेशा मॉड्यूल होते हैं। एक विधि एक मॉड्यूल है, इसलिए एक वर्ग है और एक पैकेज है। एक मॉड्यूल संगठन की एक इकाई है जिसमें आंतरिक विवरण छिपे हुए हैं, और जो सहमत अनुबंधों के माध्यम से अन्य मॉड्यूल के साथ संचार करता है। उदाहरण के लिए, एक विधि एक मॉड्यूल है क्योंकि इसमें छिपे हुए आंतरिक (कोड और स्थानीय चर) और एक अनुबंध (पैरामीटर और वापसी प्रकार) हैं। मॉड्यूल निचले-स्तर के मॉड्यूल से बना हो सकते हैं, जैसे कि कक्षाओं में विधियाँ होती हैं।

कोर जावा (प्री -9) में जो चीज गायब है वह एक तैनाती योग्य मॉड्यूल है। उपरोक्त सभी प्रकार के मॉड्यूल तैनाती योग्य इकाइयाँ नहीं हैं जिन्हें चारों ओर से कॉपी किया जा सकता है। जावा में एक जेएआर फ़ाइल नामक एक तैनाती योग्य विरूपण साक्ष्य है, लेकिन ये मॉड्यूल नहीं हैं क्योंकि उनके पास कोई एनकैप्सुलेशन या कॉन्ट्रैक्ट नहीं है: रनटाइम जेएआर फाइलों के गायब होने पर, सभी एक एकल "क्लासपाथ" में एक साथ विलय हो जाते हैं।

OSGi ने 1998 में "बंडल" की अवधारणा के साथ तैनाती योग्य मॉड्यूल की कमी को संबोधित किया। ये शारीरिक रूप से JAR फाइलें हैं और इनमें पैकेज होते हैं, लेकिन OSGi उस स्तर पर एनकैप्सुलेशन और कॉन्ट्रैक्ट्स को सपोर्ट करने के लिए रनटाइम सिस्टम के साथ अतिरिक्त मेटाडेटा को परिभाषित करता है।

जावा 9 OSGi के समान तरीके से तैनाती योग्य मॉड्यूल की कमी को संबोधित करता है। संभवतः यह पूरी तरह से अनावश्यक था क्योंकि OSGi मौजूद है और काम करता है, लेकिन यह एक पूरी अलग चर्चा है ...

दुर्भाग्य से जावा 9 नए मॉड्यूल अवधारणा को सिर्फ एक "मॉड्यूल" नाम देकर पानी को पिघला देता है। इसका मतलब यह नहीं है कि तरीके, कक्षाएं और पैकेज मॉड्यूल होने से रोकते हैं! एक J9 "मॉड्यूल" मॉड्यूल अवधारणा का सिर्फ एक और पल है । OSGi बंडलों की तरह, J9 मॉड्यूल पैकेज से बने होते हैं और वे भौतिक कलाकृतियां (आमतौर पर JAR फाइलें फिर से) होती हैं जिन्हें चारों ओर से कॉपी किया जा सकता है। रनटाइम सिस्टम उन्हें समझता है और उनका पुनरीक्षण करता है।

सारांश: हाँ J9 मॉड्यूल और पैकेज शब्दार्थ रूप से अलग-अलग धारणाएँ हैं। स्पष्ट रूप से जावा को बैकवर्ड संगतता के लिए अपनी मौजूदा पैकेज अवधारणा को बनाए रखना है। ध्यान दें कि शब्द "पैकेज" अन्य भाषाओं की तुलना में जावा में या RPM जैसे पैकेज प्रबंधन प्रणालियों में काफी भिन्न रूप से उपयोग किया जाता है। नए J9 मॉड्यूल (और OSGi बंडल) RPM के पैकेज जैसे जावा पैकेज के मुकाबले कभी ज्यादा थे।

Comments

पैकेज आपके मॉड्यूल की परिभाषा को पूरा नहीं करता है। कमजोर संकुचन और साधनों की कमी के कारण अन्य पैकेजों को एकत्र करना और उनकी दृश्यता को परिष्कृत करना। वर्गों में नेस्टेड वर्ग या फ़ील्ड हो सकते हैं। विधियों में क्लोजर शामिल हो सकते हैं या अन्य तरीकों को कॉल कर सकते हैं। संकुल अन्य संकुल के साथ "संवाद" नहीं कर सकता है।

— user2418306

मैं असहमत हूं। पैकेज में जानकारी छिपाना (डिफ़ॉल्ट एक्सेस प्रकार, तरीके और फ़ील्ड, उर्फ ​​पैकेज-निजी) है। पैकेज निश्चित रूप से "संवाद" करते हैं क्योंकि एक पैकेज के भीतर कोड अन्य पैकेजों में कोड को लागू कर सकता है। यह एक अनुबंध के खिलाफ किया जाता है, अर्थात् सार्वजनिक प्रकार और अन्य पैकेज के तरीके।

— नील बार्टलेट

ध्यान दें कि एक ही स्तर पर मॉड्यूलर कलाकृतियों को एकत्रित करने की क्षमता (जैसे क्लोजर युक्त विधियां, नेस्टेड कक्षाएं युक्त कक्षाएं) एक मॉड्यूल की मेरी परिभाषा का हिस्सा नहीं बनती हैं। यदि आप इसे मॉड्यूल परिभाषा का एक आवश्यक हिस्सा मानते हैं, तो "जावा 9 मॉड्यूल" या तो मॉड्यूल नहीं हैं।

— नील बार्लेट्ट

मैं इस बात से इनकार नहीं करता कि पैकेज में जानकारी छिपी हुई है । मैंने कहा कि यह पर्याप्त नहीं है। importपैकेज कर सकते हैं। लेकिन प्रथम श्रेणी के नागरिकों के रूप में संकुल संरचना का कोई तरीका नहीं है। उन कमियों (और OSGi की सीमाओं) को JSR 376 में वर्णित किया गया है।

— user2418306

क्या आप विस्तार से बता सकते हैं कि जावा 9 मॉड्यूल या तो मॉड्यूल क्यों नहीं हैं ?

— user2418306

Answer 2

मुझे एक उत्तर पर खतरा है, हालांकि यह बहुत कुछ मान्यताओं / विभाजन बाल / ranting, आदि हो सकता है

क्या ये एक ही चीज हैं? खैर, हाँ ^_और नहीं

से "जावा 9 में प्रतिरूपकता" के बारे में इस जावावर्ल्ड लेख :

एक मॉड्यूलर समाधान के रूप में पैकेज

संकुल जावा प्रोग्रामिंग परिदृश्य में अमूर्तता के स्तर को जोड़ने का प्रयास करता है। वे अद्वितीय कोडिंग नामस्थान और कॉन्फ़िगरेशन संदर्भों के लिए सुविधाएं प्रदान करते हैं। अफसोस की बात है, हालांकि, पैकेज सम्मेलनों को आसानी से दरकिनार किया जाता है, जो अक्सर खतरनाक संकलन-टाइम कपलिंग के वातावरण के लिए अग्रणी होता है।

जैसा कि @ user2418306 (ओपी) ने संकेत दिया, " मॉड्यूल पैकेज सही हैं " । जावा में मॉड्यूल और पैकेज (जावा 9 के रूप में, जाहिर है) हैं (जैसा कि ओपी पूछता है) शब्दार्थ समान रूप से। यही है, वे पूर्व-संकलित जेवीएम बाइटकोड के संग्रह हैं, अन्य मेटाडेटा के साथ - अनिवार्य रूप से , वे पुस्तकालय हैं ।

वैसे क्या अंतर है?

हालांकि, अंतर उनमें से प्रत्येक के अंदर मेटाडेटा में है। जावा packageमैनिफ़ेस्ट, या JAR मैनिफ़ेस्ट, अक्सर लाइब्रेरी डेवलपर्स द्वारा बनाए नहीं रखा जाता है, और न ही वे कोई निश्चित अनुबंध प्रदान करते हैं जैसा कि JAR / पैकेज प्रदान करता है। जैसा कि यहाँ बताया गया है (JavaWorld आर्टिकल फिर से) :

JAR फाइलें पर्याप्त रूप से मॉड्यूलर नहीं हैं?

JAR फाइलें और तैनाती का वातावरण जिसमें वे कई विरासत तैनाती सम्मेलनों पर बहुत सुधार करते हैं अन्यथा उपलब्ध हैं। लेकिन JAR फाइलों में कोई आंतरिक विशिष्टता नहीं है, इसके अलावा शायद ही कभी इस्तेमाल किया गया वर्जन नंबर है, जो कि ajarjar मेनिफ़ेस्ट में छिपा है। जावा रनटाइम वातावरण के भीतर JAR फ़ाइल और वैकल्पिक प्रकटन को मॉड्यूलरिटी सम्मेलनों के रूप में उपयोग नहीं किया जाता है। तो फ़ाइल में कक्षाओं के पैकेज के नाम और एक क्लासपाथ में उनकी भागीदारी JAR संरचना के एकमात्र भाग हैं जो रनटाइम वातावरण के लिए मॉड्यूलरिटी उधार देते हैं।

---

अन्य भाषाओं / परिवेशों आदि के बारे में एक शेख़ी

उस लेख में चर्चा किया गया एक अन्य क्षेत्र मावेन जैसे सिस्टम हैं , जो निर्माण प्रक्रिया के हिस्से के रूप में आपके लिए निर्भरता का प्रबंधन करते हैं। अपाचे मावेन साइट पर इस पृष्ठ से :

निर्भरता प्रबंधन:

मावेन जार और अन्य निर्भरताओं के एक केंद्रीय भंडार के उपयोग को प्रोत्साहित करता है। मावेन एक ऐसी प्रणाली के साथ आता है, जो आपके प्रोजेक्ट के ग्राहक पर्ल के सीपीएएन जैसे केंद्रीय जार भंडार से अपनी परियोजना के निर्माण के लिए आवश्यक किसी भी जेएआर को डाउनलोड करने के लिए उपयोग कर सकते हैं। यह मावेन के उपयोगकर्ताओं को परियोजनाओं में जेएआर का पुन: उपयोग करने की अनुमति देता है और परियोजनाओं के बीच संचार को प्रोत्साहित करता है ताकि यह सुनिश्चित हो सके कि पिछड़े संगतता मुद्दों से निपटा जाए।

अब भविष्य के बारे में बात करने के लिए जैसे कि मैं वहां गया हूं

जैसा कि उस पृष्ठ का उल्लेख है, अन्य भाषाओं (जैसे पर्ल) में पैकेज रिपॉजिटरी (जैसे सीपीएएन ) हैं। यह एक बढ़ती प्रवृत्ति है (मैं कहता हूं क्योंकि मुझे ऐसा लगता है, बिना किसी जोर-शोर के प्रमाण के साथ), पिछले ~ दशक या उससे अधिक। रूबी के रत्नों , पायथन के PyPi , और नोड पैकेज मैनेजर ( npm) जैसे उपकरण सही सामान (पैकेज, मॉड्यूल ) के साथ एक पर्यावरण (या तो विकास, निर्माण, परीक्षण, या रनटाइम, आदि) को कॉन्फ़िगर करने का एक सुसंगत तरीका प्रदान करने के लिए इस पर निर्माण करते हैं । रत्नों, gizmo (आदि)। एक विचार (मुझे लगता है) किया गया था " उधार " इस तरह के डेबियन के रूप में लिनक्स वितरण प्रणाली से उपयुक्त , RedHat कीrpm, आदि (हालांकि, स्पष्ट रूप से, कम से कम एक पीढ़ी विकसित हुई है , और इन चीजों को सभी अच्छे बना दिया है।)

---

जावा मॉड्यूल , हालांकि वे जरूरी कुछ भी आप पहले से ही ऐसा नहीं कर सकते, निर्भरता / पैकेज प्रबंधन और स्वचालित निर्माण वातावरण सभी के लिए मेकअप टूलींग न जोड़ें ज्यादा आसान। चाहे वह मॉड्यूल को "बेहतर" बनाता है, मैं कहना चाहता हूं। : पी

Comments

अनुच्छेद केवल 1 वर्ष पुराना है और अभी तक पहले से ही अप्रचलित है। यह बताता है कि कैसे संस्करण एक मॉड्यूल की मौलिक विशेषता है। आरा मॉड्यूल में संस्करण की जानकारी नहीं होगी। अंतिम उपयोगकर्ता के लिए निर्भरता प्रबंधन के दायरे में कुछ भी नहीं बदलेगा। उपकरण बनाने के लिए चीजें वास्तव में बहुत कठिन हो जाएंगी। के रूप में वे के समानांतर वास्तविकताओं suport करने की जरूरत है classpathऔर modulepath। और इकाई परीक्षण का समर्थन करने के लिए हुप्स के माध्यम से कूदें। परिसर दो अवधारणाओं के समतुल्य है क्योंकि वे चीजों के संग्रह का प्रतिनिधित्व करते हैं और साथ ही मेटाडेटा भी स्वीकार करने के लिए बहुत बोल्ड है। प्लस बीच में आपने अचानक पैकेज के लिए जार प्रतिस्थापित किया है।

— user2418306

मैंने यह नहीं कहा कि " दो अवधारणाएँ बराबर हैं ", मैंने कहा कि वे "शब्दार्थ वही हैं" - जो आपने पूछा है। इसके अलावा, आपने प्रश्न का संपादन किया है क्योंकि मैंने विशेष रूप से JSR-376 का उल्लेख करने के लिए उत्तर दिया था , जो कि आरा का विरोध करता है, जो कि पहले कहा गया था: - /

— Tersosauros

आरा में शामिल हैं (कार्यान्वयन) JSR-376। प्रश्न अभी भी दोनों को जोड़ता है, इसलिए कोई नुकसान नहीं हुआ। शब्दकोश समान अर्थ होने की गुणवत्ता या स्थिति के रूप में समानता को परिभाषित करता है। और शब्दार्थ - अर्थ के संबंध में। मुझे क्षमा करें, लेकिन आप यहां गलत विवरण के बारे में बता रहे हैं। आपने कहा है कि वे समान हैं। लेकिन आपने कोई तर्क नहीं दिया। इसके बजाय आप उस लेख को देखें जो यह बताता है कि पैकेज और जार मॉड्यूल कैसे विफल होते हैं। लेकिन आगामी मॉड्यूल लेख से भी मॉड्यूल होने में विफल रहते हैं। समतुल्यता का दावा करना और फिर 2 (3) के बीच अंतर प्रदान करना आत्म विरोधाभासी है।

— user2418306

प्रश्न का उत्तर हां और नहीं हो सकता है। या तो शब्द दो अवधारणाएँ समतुल्य हैं या नहीं। कृपया मेरी टिप्पणियों की पैरवी न करें और मूल प्रश्न पर लौटें। क्या किसी भाषा को दोनों अवधारणाओं की आवश्यकता है या यह जावा विरासत विशिष्ट मुद्दा है? यदि आपको स्पष्टीकरण की आवश्यकता है तो मुझे मदद करने में खुशी होगी।

— user2418306