जावा का पैकेज मैनेजमेंट सिस्टम मुझे हमेशा सरल और प्रभावी लगता था। इसका उपयोग JDK द्वारा ही किया जाता है। हम इसका उपयोग नामस्थान और मॉड्यूल की अवधारणा की नकल करने के लिए कर रहे हैं।
क्या है प्रोजेक्ट Jigsaw (उर्फ जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम ) में भरने की कोशिश कर रहा?
आधिकारिक साइट से:
इस परियोजना का लक्ष्य जावा एसई प्लेटफॉर्म के लिए एक मानक मॉड्यूल प्रणाली को डिजाइन और कार्यान्वित करना है, और उस सिस्टम को स्वयं प्लेटफॉर्म और जेडीके के लिए लागू करना है।
जवाबों:
आरा और ओएसजीआई एक ही समस्या को हल करने की कोशिश कर रहे हैं: कैसे अपने आंतरिक परिरक्षण करते समय मोटे अनाज वाले मॉड्यूल को बातचीत करने की अनुमति दें।
आरा के मामले में, मोटे अनाज वाले मॉड्यूल में जावा वर्ग, पैकेज और उनकी निर्भरताएं शामिल हैं।
यहाँ एक उदाहरण है: स्प्रिंग और हाइबरनेट। दोनों के पास 3rd पार्टी JAR CGLIB पर निर्भरता है, लेकिन वे उस JAR के विभिन्न, असंगत संस्करणों का उपयोग करते हैं। यदि आप मानक JDK पर भरोसा करते हैं तो आप क्या कर सकते हैं? उस संस्करण को शामिल करना, जिसमें स्प्रिंग हाइबरनेट और वीज़ा वर्सा को तोड़ना चाहता है।
लेकिन, यदि आपके पास आरा जैसा उच्च-स्तरीय मॉडल है, तो आप आसानी से एक JAR के विभिन्न संस्करणों को विभिन्न मॉड्यूल में प्रबंधित कर सकते हैं। उन्हें उच्च-स्तरीय पैकेज समझें।
यदि आप GitHub स्रोत से स्प्रिंग बनाते हैं तो आप इसे देखेंगे। उन्होंने रूपरेखा को फिर से तैयार किया है, जिसमें कई मॉड्यूल शामिल हैं: कोर, दृढ़ता, आदि। आप मॉड्यूल निर्भरता के न्यूनतम सेट को चुन सकते हैं और चुन सकते हैं जो आपके आवेदन की आवश्यकता है और बाकी को अनदेखा करें। यह एक सिंगल स्प्रिंग JAR हुआ करता था, जिसमें सभी .class फाइलें थीं।
अद्यतन: पांच साल बाद - आरा में अभी भी कुछ मुद्दे हल हो सकते हैं।
NoSuchMethodErrorऔर NoClassDefFoundError।
AFAIK JRE को अधिक मॉड्यूलर बनाने की योजना है। यानी छोटे जार हैं जो वैकल्पिक हैं और / या आप केवल उसी कार्यक्षमता को डाउनलोड / अपग्रेड कर सकते हैं जिसकी आपको आवश्यकता है।
इसका इसे कम फूला हुआ बनाने के लिए और आपको विरासत मॉड्यूल को छोड़ने का विकल्प दिया जाता है, जो शायद ज्यादातर लोग उपयोग नहीं करते हैं।
importयह सब करते हैं, तो इस वर्ग को संकलक के लिए कक्षा के नाम स्थान में लाया जाता है। यदि आप वास्तव में इसका उपयोग नहीं करते हैं, तो यह बनाए गए बाइट कोड में दिखाई नहीं देगा। यदि आप वास्तव में कक्षा का उपयोग करते हैं, तो आपको उस वर्ग और प्रत्येक वर्ग के लिए रनटाइम का उपयोग करना होगा। सिद्धांत रूप में आप अमरूद एपीआई का एक कट डाउन संस्करण बना सकते हैं, जिसमें आपको केवल वही चाहिए जो इसके बदले आपको चाहिए और उस जार का उपयोग करें। वास्तव में, यह त्रुटि प्रवण है और अधिकांश मामलों में बहुत उपयोगी नहीं है, और आप अंत में जारी किए गए अनुसार पूरे जार को जोड़ते हैं।
डेक्सॉक्स बेल्जियम में मार्क रेनहोल्ड के मुख्य भाषण के आधार पर , प्रोजेक्ट आरा दो मुख्य दर्द बिंदुओं को संबोधित करने जा रहा है:
हम सभी JAR नर्क के बारे में जानते हैं । यह शब्द उन सभी विभिन्न तरीकों का वर्णन करता है जिनमें क्लासलोडिंग प्रक्रिया समाप्त हो सकती है, काम नहीं कर रही है। क्लासपाथ की सबसे ज्ञात सीमाएं हैं:
JDK की बड़ी अखंड प्रकृति कई समस्याओं का कारण बनती है:
उपरोक्त समस्याओं को दूर करने के लिए, हम मॉड्यूल को मौलिक नई तरह के जावा प्रोग्राम घटक के रूप में मानते हैं। एक मॉड्यूल कोड और डेटा का एक नाम, आत्म-वर्णन संग्रह है। इसका कोड संकुल के एक प्रकार के रूप में आयोजित किया जाता है, अर्थात, जावा वर्ग और इंटरफेस; इसके डेटा में संसाधन और अन्य प्रकार की स्थिर जानकारी शामिल है।
यह नियंत्रित करने के लिए कि इसका कोड अन्य मॉड्यूल के प्रकारों को कैसे संदर्भित करता है, एक मॉड्यूल घोषित करता है कि किन अन्य मॉड्यूलों को संकलित करने और चलाने के लिए इसकी आवश्यकता है। यह नियंत्रित करने के लिए कि अन्य मॉड्यूल में कोड अपने पैकेजों के प्रकारों को कैसे संदर्भित करता है, एक मॉड्यूल घोषित करता है कि वह उन पैकेजों में से कौन सा निर्यात करता है।
मॉड्यूल सिस्टम आवश्यक मॉड्यूल का पता लगाता है और वर्ग-पथ तंत्र के विपरीत, यह सुनिश्चित करता है कि एक मॉड्यूल में कोड केवल उन मॉड्यूल के प्रकारों को संदर्भित कर सकता है जिन पर यह निर्भर करता है। जावा भाषा और जावा वर्चुअल मशीन का एक्सेस-कंट्रोल मैकेनिज्म कोड को उन पैकेजों में एक्सेस करने से रोकता है जो उनके डिफाइनिंग मॉड्यूल द्वारा एक्सपोर्ट नहीं किए जाते हैं।
अधिक विश्वसनीय होने के अलावा, मॉड्यूलरिटी प्रदर्शन में सुधार कर सकती है। जब एक मॉड्यूल में कोड एक पैकेज में एक प्रकार को संदर्भित करता है तो उस पैकेज को या तो उस मॉड्यूल में परिभाषित किया जाता है या उस मॉड्यूल द्वारा पढ़े गए मॉड्यूल में से एक में सटीक रूप से परिभाषित किया जाता है। जब एक विशिष्ट प्रकार की परिभाषा की तलाश होती है, इसलिए, पूरे वर्ग पथ के साथ, कई मॉड्यूल में या इससे भी बदतर, इसके लिए खोज करने की कोई आवश्यकता नहीं है।
आरा एक बहुत बड़ा प्रोजेक्ट है जो काफी सालों से चल रहा है। इसे JEP की प्रभावशाली राशि मिली है जो परियोजना के बारे में अधिक जानकारी प्राप्त करने के लिए शानदार स्थान हैं। इनमें से कुछ JEP निम्नलिखित हैं:
द स्टेट ऑफ़ द मॉड्यूल सिस्टम रिपोर्ट के प्रारंभिक संस्करण में , मार्क रीनहोल्ड ने मॉड्यूल सिस्टम के विशिष्ट लक्ष्यों का वर्णन निम्नानुसार किया है:
इन सुविधाओं से एप्लिकेशन डेवलपर्स, लाइब्रेरी डेवलपर्स, और जावा एसई प्लेटफॉर्म के कार्यान्वयनकर्ताओं को सीधे और साथ ही, अप्रत्यक्ष रूप से लाभ होगा, क्योंकि वे एक स्केलेबल प्लेटफॉर्म, अधिक प्लेटफॉर्म अखंडता और बेहतर प्रदर्शन को सक्षम करेंगे।
तर्क के लिए, आइए दावा करते हैं कि जावा 8 (और पहले) में पहले से ही मॉड्यूल (जार) और मॉड्यूल सिस्टम (क्लासपाथ) का "फॉर्म" है। लेकिन इन के साथ अच्छी तरह से ज्ञात समस्याएं हैं।
समस्याओं की जांच करके, हम आरा के लिए प्रेरणा का वर्णन कर सकते हैं। (निम्नलिखित अनुमान हम OSGi, JBoss मॉड्यूल, आदि का उपयोग नहीं कर रहे हैं, जो निश्चित रूप से समाधान प्रदान करते हैं।)
समस्या 1: सार्वजनिक भी सार्वजनिक है
निम्नलिखित वर्गों पर विचार करें (मान लें कि दोनों सार्वजनिक हैं):
com.acme.foo.db.api.UserDao
com.acme.foo.db.impl.UserDaoImpl
Foo.com पर, हम यह तय कर सकते हैं कि हमारी टीम को उपयोग करना चाहिए UserDaoऔर उपयोग नहीं करना चाहिएUserDaoImpl सीधे । हालाँकि, क्लासपाथ पर इसे लागू करने का कोई तरीका नहीं है।
आरा में, एक मॉड्यूल में एक module-info.javaफ़ाइल होती है जो हमें स्पष्ट रूप से यह बताने की अनुमति देती है कि अन्य मॉड्यूल के लिए सार्वजनिक क्या है। अर्थात्, जनता के पास बारीकियों है। उदाहरण के लिए:
// com.acme.foo.db.api.UserDao is accessible, but
// com.acme.foo.db.impl.UserDaoImpl is not
module com.acme.foo.db {
exports com.acme.foo.db.api;
}
समस्या 2: प्रतिबिंब बेलगाम है
# 1 में कक्षाओं को देखते हुए, कोई भी अभी भी जावा 8 में ऐसा कर सकता है:
Class c = Class.forName("com.acme.foo.db.impl.UserDaoImpl");
Object obj = c.getConstructor().newInstance();
यह कहना है: प्रतिबिंब शक्तिशाली और आवश्यक है, लेकिन अगर अनियंत्रित है, तो इसका उपयोग अवांछनीय तरीकों से एक मॉड्यूल के आंतरिक में पहुंचने के लिए किया जा सकता है। मार्क रेनहोल्ड का एक बल्कि भयावह उदाहरण है । (एसओ पद यहां है ।)
आरा में, मजबूत एनकैप्सुलेशन प्रतिबिंब सहित एक वर्ग तक पहुंच से इनकार करने की क्षमता प्रदान करता है। (यह कमांड लाइन सेटिंग्स पर निर्भर हो सकता है, JDK 9 के लिए संशोधित टेक कल्पना लंबित है।) ध्यान दें कि आरा का उपयोग JDK के लिए ही किया जाता है, ओरेकल का दावा है कि इससे जावा टीम प्लेटफ़ॉर्म इंटर्ल्स को और अधिक तेज़ी से नवाचार करने की अनुमति देगा।
समस्या 3: क्लासपाथ वास्तु संबंधों को मिटा देता है
एक टीम में आम तौर पर जार के बीच संबंधों के बारे में एक मानसिक मॉडल होता है। उदाहरण के लिए, foo-app.jarउपयोग हो सकता है foo-services.jarजो उपयोग करता है foo-db.jar। हम foo-app.jar"सर्विस लेयर" को बायपास नहीं करना चाहिए और foo-db.jarसीधे उपयोग करना चाहिए । हालांकि, क्लासपैथ के माध्यम से इसे लागू करने का कोई तरीका नहीं है। मार्क रीनहोल्ड ने यहां इसका उल्लेख किया है ।
तुलना करके, आरा मॉड्यूल के लिए एक स्पष्ट, विश्वसनीय पहुंच मॉडल प्रदान करता है।
समस्या 4: अखंड रन-टाइम
जावा रनटाइम अखंड में है rt.jar। मेरी मशीन पर, 20k वर्गों के साथ यह 60+ एमबी है! सूक्ष्म सेवाओं, IoT उपकरणों, आदि के युग में, यदि उनका उपयोग नहीं किया जा रहा है, तो डिस्क पर कोरबा, स्विंग, एक्सएमएल और अन्य पुस्तकालयों का होना अवांछनीय है।
आरा कई मॉड्यूल में जेडीके को ही तोड़ता है ; उदाहरण के लिए java.sql में परिचित SQL कक्षाएं हैं। इसके कई लाभ हैं, लेकिन एक नया jlinkउपकरण है। एक ऐप को पूरी तरह से संशोधित माना जाता है, jlinkएक वितरण योग्य रन-टाइम छवि उत्पन्न करता है जिसे केवल निर्दिष्ट मॉड्यूल (और उनकी निर्भरता) को शामिल करने के लिए छंटनी की जाती है। आगे की ओर देखते हुए, ओरेकल भविष्य को आगे बढ़ाता है जहां जेडडीके मॉड्यूल को मूल कोड में आगे-आगे संकलित किया जाता है। हालांकि jlinkवैकल्पिक है, और एओटी संकलन प्रयोगात्मक है, वे प्रमुख संकेत हैं जहां ओरेकल का नेतृत्व किया जाता है।
समस्या 5: संस्करण
यह सर्वविदित है कि क्लासपैथ हमें एक ही जार के कई संस्करणों का उपयोग करने की अनुमति नहीं देता है: जैसे bar-lib-1.1.jarऔर bar-lib-2.2.jar।
आरा इस समस्या को संबोधित नहीं करता है; मार्क रीनहोल्ड ने यहां तर्क दिया है । सार यह है कि मावेन, ग्रैडल और अन्य उपकरण निर्भरता प्रबंधन के लिए एक बड़े पारिस्थितिकी तंत्र का प्रतिनिधित्व करते हैं, और एक अन्य समाधान लाभकारी से अधिक हानिकारक होगा।
यह ध्यान दिया जाना चाहिए कि अन्य समाधान (जैसे OSGi) वास्तव में इस समस्या को संबोधित करते हैं (और अन्य, # 4 से अलग)।
जमीनी स्तर
आरा के लिए कुछ प्रमुख बिंदु, विशिष्ट समस्याओं से प्रेरित हैं।
ध्यान दें कि आरा, OSGi, JBoss मॉड्यूल, आदि के बीच विवाद की व्याख्या एक अलग चर्चा है जो किसी अन्य स्टैन एक्सचेंज साइट पर है। यहाँ वर्णित की तुलना में समाधानों के बीच कई और अंतर हैं। क्या अधिक है, JSR 376 के लिए सार्वजनिक समीक्षा पुनर्विचार मतदान को अनुमोदित करने के लिए पर्याप्त सहमति थी ।
यह आलेख उन समस्याओं के बारे में विस्तार से बताता है, जो OSGi और JPMS / आरा दोनों को हल करने की कोशिश करते हैं:
"जावा 9, ओएसजीआई एंड द फ्यूचर ऑफ मॉड्युलरिटी" [22 एसईपी 2016]
यह OSGi और JPMS / आरा दोनों के दृष्टिकोण में पूरी तरह से चला जाता है। अब तक, यह प्रकट होता है कि लेखक परिपक्व (16 वर्ष) के ओएसजीआई की तुलना में जेपीएमएस / आरा के लिए लगभग कोई व्यावहारिक पेशेवरों को सूचीबद्ध नहीं करते हैं।