क्या जावा-जेडैक (जेडीके 9) में क्लास-पथ और - मॉड्यूल-पथ को मिश्रित करना संभव है?

Question

जब मैं एक मॉड्यूल संकलित करता हूं जो कि अन्य मॉड्यूल पर निर्भर करता है जिसे मैंने पहले संकलित किया है, मुझे --module-path <directory> विकल्प निर्दिष्ट करना होगा। यह मॉड्यूल बनाता है जो मैं दृश्यमान पर निर्भर करता हूं।

लेकिन साथ ही मैं कुछ गैर मॉड्यूलर जार फ़ाइलों को भी दिखाना चाहूंगा। हालांकि अगर उन्हें स्वचालित मॉड्यूल नहीं बनाते हैं और बस --class-path some.jar को --module-path <directory> के बगल में निर्दिष्ट करें, तो javac क्लैपथ को अनदेखा करता है और "पैकेज yyy नहीं मिला" और अन्य "नहीं मिला" त्रुटियों को फेंकता है।

मैं समझ सकता है कि एक ही (संकलन) समय में --class-path और --module-path का उपयोग कर अवैध है, लेकिन javac किसी भी तरह से इसके खिलाफ मुझे चेतावनी नहीं है।

Answer 1

आप समानांतर में कक्षा पथ और मॉड्यूल पथ का उपयोग कर सकते हैं, लेकिन विचार करने के लिए कुछ विवरण हैं।

निर्भरता मॉड्यूल पथ ~> कक्षा पथ

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

चूंकि मॉड्यूल को इसकी सभी निर्भरताओं की आवश्यकता होनी चाहिए और उनको केवल अन्य नामित मॉड्यूल (यानी कक्षा पथ पर जार नहीं) द्वारा पूरा किया जा सकता है, मॉड्यूलर जेएआर की सभी निर्भरताओं को मॉड्यूल पथ पर रखा जाना चाहिए। हां, यहां तक ​​कि गैर मॉड्यूलर जेएआर, जो तब automatic modules में बदल जाएगा।

दिलचस्प बात यह है कि स्वत: मॉड्यूल , अनाम मॉड्यूल पढ़ा तो उनके निर्भरता वर्ग रास्ते पर जा सकते हैं कर सकते हैं।

निर्भरता कक्षा पथ ~> मॉड्यूल पथ

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

तो यदि मॉड्यूल पथ पर गैर-मॉड्यूलर कोड कलाकृतियों पर निर्भर करता है, तो आपको उन्हें the --add-modules option के साथ मैन्युअल रूप से जोड़ने की आवश्यकता है। जरूरी नहीं कि वे सभी, जो आप सीधे निर्भर करते हैं (मॉड्यूल सिस्टम संक्रमणीय निर्भरताओं में खींच जाएगा) - या आप ALL-MODULE-PATH का उपयोग कर सकते हैं (लिंक किए गए पोस्ट की जांच करें, यह अधिक विस्तार से बताता है)।

Answer 2

मैं एक ही समय में --classpath और --module-path विकल्पों का उपयोग कर विश्वास करते हैं अवैध नहीं है। वर्तमान निर्देशिका में डिफ़ॉल्ट को स्पष्ट रूप से क्लासपाथ निर्दिष्ट नहीं करते समय भी दोनों का उपयोग करना संभव है। javac -help संदेश से

विवरण और javac tools docs -

--module-path <path>, -p <path> 

निर्दिष्ट करें जहां आवेदन मॉड्यूल को खोजने के लिए

--class-path <path>, -classpath <path>, -cp <path> 

निर्दिष्ट करें जहां उपयोगकर्ता वर्ग फ़ाइलों और एनोटेशन प्रोसेसर

तो लगता है --class-path, -classpath, या -cpनिर्दिष्ट नहीं हैं, तो उपयोगकर्ता कक्षा पथ वर्तमान निर्देशिका है।

---

संपादित: @MouseEvent के लिए धन्यवाद, मैं शायद बाहर भाग सवाल में याद किया था

लेकिन अगर उन्हें स्वत: मॉड्यूल नहीं बनाते हैं और सिर्फ निर्दिष्ट - क्लास-पथ कुछ .jar - मॉड्यूल-पथ के ठीक आगे, फिर जावैक क्लैपथ को अनदेखा करता है और "पैकेज yyy नहीं मिला" और अन्य "नहीं मिला" त्रुटियां फेंकता है।

आप उन्हें स्वत: नहीं बनाते हैं, यह एक Module System's unnamed module के रूप में देखा जाता है और -

एक नामित मॉड्यूल नहीं, वास्तव में, यहां तक ​​कि अनाम मॉड्यूल ऊपर निर्भर करना घोषणा कर सकते हैं। यह प्रतिबंध जानबूझकर है, क्योंकि क्लास पथ की मनमानी सामग्री पर निर्भर करने के लिए मॉड्यूल नामित करने की अनुमति विश्वसनीय कॉन्फ़िगरेशन असंभव बनाती है।

इसके अलावा, अनाम मॉड्यूल निर्यात अपने संकुल के सभी इसलिए एक स्वत: मॉड्यूल में कोड भी सार्वजनिक प्रकार classpath से लोड उपयोग करने में सक्षम हो जाएगा।

लेकिन एक स्वचालित मॉड्यूल जो क्लासपाथ से प्रकारों का उपयोग करता है, उस प्रकार को स्पष्ट मॉड्यूल पर प्रदर्शित नहीं करना चाहिए जो पर निर्भर करता है, क्योंकि स्पष्ट मॉड्यूल अज्ञात मॉड्यूल पर निर्भरता घोषित नहीं कर सकते हैं।

स्पष्ट मॉड्यूल com.foo.app में कोड एक सार्वजनिक प्रकार com.foo.bar में , जैसे को संदर्भित करता है, और उस प्रकार के हस्ताक्षर, तो वर्ग पथ पर जार फ़ाइलों को अभी भी से एक में एक प्रकार को संदर्भित करता है, तो com.foo.app com.foo.app के बाद से उस प्रकार तक पहुंचने में सक्षम नहीं होगा, नामित मॉड्यूल पर निर्भर नहीं हो सकता है।

इस वर्ग के रास्ते पर प्रासंगिक JAR फ़ाइल के रूप में एक स्वत: मॉड्यूल के रूप में com.foo.app इलाज अस्थायी रूप से इतना है कि अपने कोड वर्ग पथ से प्रकार का उपयोग कर सकते, जब तक, द्वारा ठीक किया जा सकता है एक स्वचालित मॉड्यूल के रूप में इलाज किया जा सकता या एक स्पष्ट मॉड्यूल में परिवर्तित।