2017-05-25 24 views
6

जावा 9 मॉड्यूल सिस्टम में java.se मॉड्यूल क्यों है जिसमें अन्य मॉड्यूल पर संक्रमणीय निर्भरता है। यह पूर्व जावा 9 दुनिया में पूरे rt.jar के आधार पर समान नहीं है।जावा 9 में java.se मॉड्यूल का महत्व क्या है?

module java.se { 
    requires transitive java.desktop; 
    requires transitive java.security.jgss; 
    requires transitive java.security.sasl; 
    requires transitive java.management; 
    requires transitive java.logging; 
    requires transitive java.datatransfer; 
    requires transitive java.sql.rowset; 
    requires transitive java.compiler; 
    requires transitive java.sql; 
    requires transitive java.naming; 
    requires transitive java.prefs; 
    requires transitive java.rmi; 
    requires transitive java.xml.crypto; 
    requires transitive java.management.rmi; 
    requires transitive java.xml; 
    requires transitive java.scripting; 
    requires transitive java.instrument; 
} 
+1

यह आश्चर्यजनक क्यों है? यह सुविधाजनक लगता है, अन्यथा आपको प्रत्येक निर्भरता को मैन्युअल रूप से शामिल करना होगा। –

+4

'java.se' में मॉड्यूल का केवल सीमित सेट शामिल है। मॉड्यूल का पूरा सेट बहुत बड़ा है: जावाएफएक्स, एक्सएमएल, कॉर्बा इत्यादि – ZhekaKozlov

+0

@ जोर्नवर्नी- मुझे लगता है कि हमें मैन्युअल रूप से अधिकांश मॉड्यूल निर्भरताओं को शामिल करना होगा। उन संक्रमणीय स्वचालित रूप से हल हो जाएंगे –

उत्तर

8

जहां तक ​​मैं मुख्य कारण बता सकता हूं गैर मॉड्यूलर जावा ईई कोड के साथ संगतता है। जब कोड जिसमें कोई मॉड्यूल घोषणा या वर्णनकर्ता नहीं होता है (जो इसकी निर्भरता को परिभाषित करता है) संकलित या लॉन्च किया जाता है, तो सवाल उठता है कि जेडीके से कौन से मॉड्यूल को "देखने" की अनुमति है।

यदि वे जेडीके में सभी मॉड्यूल थे, तो जावा ईई वाले क्लास पथ पर रखे गए किसी भी जावा ईई कार्यान्वयन को "ओवरहाडो" करेंगे। यह मॉड्यूल और कक्षा पथ (जो अज्ञात मॉड्यूल में समाप्त होता है) के बीच बातचीत की एक विशिष्टता है: यदि एक नियमित मॉड्यूल और अनामित दोनों में एक पैकेज मौजूद है, तो बाद वाला प्रभावी रूप से अदृश्य हो जाएगा।

उस तथ्य को हल करने के लिए सभी मॉड्यूल कक्षा पथ पर कोड के लिए दिखाई नहीं देंगे। इसके बजाए, मॉड्यूल रिज़ॉल्यूशन (जो किसी एप्लिकेशन की निर्भरता को हल करता है) रूट मॉड्यूल java.se में शुरू होगा, इस प्रकार जावा ईई मॉड्यूल को अनदेखा कर देगा।

एक अधिक विस्तृत विवरण के लिए, this mail from Alan Bateman पर एक नज़र, जिसमें उन्होंने इसी JEP 261 के परिवर्तन बताते है।

+0

धन्यवाद! मैंने सोचा कि पिछड़ा संगतता जार अभी भी जेडीके -9 में होगा। –

+1

वे पूरी तरह से हैं! जार अभी भी कक्षाओं को शिप करने के लिए प्राथमिक कंटेनर हैं। एकमात्र परिवर्तन यह है कि उनमें एक मॉड्यूल डिस्क्रिप्टर ('मॉड्यूल-info.class') हो सकता है, इस मामले में वे एक _modular JAR_ हैं। – Nicolai

2

java.se मॉड्यूल मॉड्यूल (उर्फ "जड़ मॉड्यूल") जावा 9. में अनुप्रयोगों आप ठीक कह रहे हैं के लिए उपलब्ध के डिफ़ॉल्ट सेट कि java.se मॉड्यूल क्या बड़े JDKs की rt.jar में था के बारे में 80% है (अगर आप rt.jar पूर्ण करना चाहते हैं java.se.ee मॉड्यूल पर एक नज़र डालें)।

जावा 9 मॉड्यूलरिटी का एक प्रमुख लाभ नई jlink उपयोगिता है, जो आपके जेडीके को आवश्यक मॉड्यूल में "छोटा" कर देगा। उदाहरण के लिए, मान लें कि आप एक बहुत ही सरल जावा ऐप लिखते हैं जो केवल java.base मॉड्यूल पर निर्भर करता है और आप सबसे छोटे संभव रूप में वितरित करना चाहते हैं। आप एक जेडीके छवि बनाने के लिए jlink उपयोगिता चला सकते हैं जिसमें केवल java.base मॉड्यूल शामिल होगा, क्योंकि यह आपके सभी एप्लिकेशन को चलाने के लिए आवश्यक है।

वापस java.se मॉड्यूल के लिए हो रही है, यह शायद एक मॉड्यूल requires java.se क्योंकि इस jlink कभी कि मॉड्यूल या किसी अन्य मॉड्यूल है कि इस पर निर्भर के लिए एक अच्छी छोटी JDK छवि बनाने की संभावना को बर्बाद होगा लिखने के लिए मूर्ख होगा। एक आदर्श दुनिया में, सभी मॉड्यूल सटीक मॉड्यूल घोषित करते हैं जिनकी उन्हें आवश्यकता होती है।

+1

कॉम्पैक्ट एग्रीगेटर मॉड्यूल कुछ समय पहले हटा दिए गए थे। – Nicolai

+0

यह इंगित करने के लिए धन्यवाद, मैंने अपना जवाब अपडेट कर लिया है। अफसोस की बात है कि जेईपी 261 पृष्ठ अभी भी उनका उल्लेख करता है इसलिए मुझे लगता है कि वे अभी भी अस्तित्व में हैं ... –

संबंधित मुद्दे