जावा क्लासलोडर: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
 
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''[[जावा क्लास]] लोडर''' [[जावा क्रम पर्यावरण|जावा रनटाइम एनवायरनमेंट]] का एक भाग है जो जावा क्लास को [[जावा वर्चुअल मशीन|जावा आभासी मशीन (वर्चुअल मशीन)]] में [[गतिशील लोडिंग|गतिशील]] रूप से लोड करता है।<ref>{{cite web
'''[[जावा क्लास]] लोडर''' [[जावा क्रम पर्यावरण|जावा रनटाइम एनवायरनमेंट]] का एक भाग है जो जावा क्लास को [[जावा वर्चुअल मशीन]] में [[गतिशील लोडिंग|डाइनामिकाली]] लोड करता है।<ref>{{cite web
  |last1=Mcmanis |first1=Chuck
  |last1=Mcmanis |first1=Chuck
  |date=1996-10-01 |df=mdy
  |date=1996-10-01 |df=mdy
Line 6: Line 6:
  |work=[[JavaWorld]]
  |work=[[JavaWorld]]
  |accessdate=2020-07-13
  |accessdate=2020-07-13
}}</ref> सामान्यतः क्लासेस केवल अनुरोध पर ही लोडित की जाती हैं। वर्चुअल मशीन केवल प्रोग्राम को निष्पादित करने के लिए आवश्यक क्लास फ़ाइलों को लोडित करेगी।{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} जावा रन टाइम सिस्टम को फ़ाइलों और फ़ाइल सिस्टम के विषय में परिचित होने की आवश्यकता नहीं है क्योंकि यह क्लास लोडर को प्रत्यायोजित किया गया है।
}}</ref> सामान्यतः क्लासेस केवल अनुरोध पर ही लोड की जाती हैं। वर्चुअल मशीन केवल प्रोग्राम को निष्पादित करने के लिए आवश्यक क्लास फ़ाइल को लोड करेगी।{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} जावा रन टाइम सिस्टम को फ़ाइल और फ़ाइल सिस्टम के विषय में परिचित होने की आवश्यकता नहीं है क्योंकि यह क्लास लोडर को प्रत्यायोजित किया गया है।


एक सॉफ़्टवेयर [[लाइब्रेरी (कंप्यूटिंग)]] संबंधित [[ वस्तु कोड |ऑब्जेक्ट कोड]] का एक संग्रह है। [[जावा (प्रोग्रामिंग भाषा)]] में, लाइब्रेरीज़ को सामान्यतः JAR फ़ाइलों में पैक किया जाता है। लाइब्रेरी में विभिन्न प्रकार के ऑब्जेक्ट हो सकते हैं। जार फ़ाइल में सम्मिलित ऑब्जेक्ट का अधिक महत्वपूर्ण प्रकार जावा क्लास है। एक वर्ग को कोड की नामित इकाई के रूप में सोचा जा सकता है। क्लास लोडर पुस्तकालयों का पता लगाने, उनकी सामग्री को पढ़ने और पुस्तकालयों के भीतर मौजूद कक्षाओं को लोड करने के लिए जिम्मेदार है। यह लोडिंग आम तौर पर मांग पर की जाती है, इसमें यह तब तक नहीं होता है जब तक प्रोग्राम द्वारा क्लास को कॉल नहीं किया जाता है। किसी दिए गए नाम वाली क्लास को दिए गए क्लास लोडर द्वारा केवल एक बार लोड किया जा सकता है।
एक सॉफ़्टवेयर [[लाइब्रेरी (कंप्यूटिंग)]] संबंधित [[ वस्तु कोड |ऑब्जेक्ट कोड]] का एक संग्रह है। [[जावा (प्रोग्रामिंग भाषा)|जावा (प्रोग्रामिंग लैंग्वेज)]] में, लाइब्रेरीज़ को सामान्यतः JAR फ़ाइलों में पैक किया जाता है। लाइब्रेरी में विभिन्न प्रकार के ऑब्जेक्ट हो सकते हैं। जार फ़ाइल में सम्मिलित ऑब्जेक्ट का अधिक महत्वपूर्ण प्रकार जावा क्लास है। एक क्लास को यूनिट ऑफ़ कोड के रूप में विचारा जा सकता है। क्लास लोडर लाइब्रेरी का स्थान निर्धारण, उनकी विषय सूची का अध्ययन तथा लाइब्रेरी के भीतर उपस्थित क्लासेस को लोड करने के लिए उत्तरदायी है। यह लोडिंग सामान्यतः "ऑन डिमांड" की जाती है, ऐसा तब तक नहीं होता है जब तक प्रोग्राम द्वारा क्लास को कॉल नहीं किया जाता है। किसी नामित क्लास को दिए गए क्लास लोडर द्वारा केवल एक बार लोड किया जा सकता है।


प्रत्येक जावा क्लास को क्लास लोडर द्वारा लोड किया जाना चाहिए।{{sfn | Horstmann | 2022 | loc=§8.2.5 Writing Byte Codes to Memory}}<ref name="Christudas">{{cite web
प्रत्येक जावा क्लास को क्लास लोडर द्वारा ही लोड किया जाना चाहिए।{{sfn | Horstmann | 2022 | loc=§8.2.5 Writing Byte Codes to Memory}}<ref name="Christudas">{{cite web
  |last1=Christudas |first1=Binildas
  |last1=Christudas |first1=Binildas
  |date=2005-01-26 |df=mdy
  |date=2005-01-26 |df=mdy
Line 18: Line 18:
  |archivedate=2018-05-10
  |archivedate=2018-05-10
  |work=onjava.com
  |work=onjava.com
}}</ref> इसके अलावा, [[जावा (सॉफ़्टवेयर प्लेटफ़ॉर्म)]] प्रोग्राम लाइब्रेरी (कंप्यूटिंग) का उपयोग कर सकते हैं (अर्थात, प्रोग्राम के लेखक के अलावा किसी अन्य द्वारा लिखित और प्रदान की गई लाइब्रेरी) या वे कम से कम आंशिक रूप से कई लाइब्रेरी से बने हो सकते हैं .
}}</ref> इसके अतिरिक्त, [[जावा (सॉफ़्टवेयर प्लेटफ़ॉर्म)]] एक्सटर्नल लाइब्रेरी का उपयोग कर सकते हैं (अर्थात, प्रोग्रामर के अतिरिक्त किसी अन्य द्वारा लिखित और प्रदान की गई लाइब्रेरी) या सम्भवतः उन्हें अनेक लाइब्रेरी के भागों में निर्माण किया जा सकता है।


जब JVM प्रारंभ किया जाता है, तो तीन क्लास लोडर का उपयोग किया जाता है:<ref name="TJT:UECL">{{cite web
जब JVM प्रारंभ किया जाता है, तो तीन क्लास लोडर का उपयोग किया जाता है:<ref name="TJT:UECL">{{cite web
Line 38: Line 38:
# सिस्टम क्लास लोडर
# सिस्टम क्लास लोडर


बूटस्ट्रैप क्लास लोडर कोर जावा लाइब्रेरीज़ को लोड करता है<ref group=fn>These libraries are stored in [[JAR (file format)|Jar files]] called ''rt.jar'', ''core.jar'', ''server.jar'', etc.</ref> में स्थित <code><JAVA_HOME>/jre/lib</code> (या <code><JAVA_HOME>/jmods></code> जावा 9 और उससे ऊपर के लिए) निर्देशिका। यह क्लास लोडर, जो कोर जेवीएम का हिस्सा है, मूल कोड में लिखा गया है। बूस्ट्रैप क्लास लोडर किसी से संबद्ध नहीं है {{java|ClassLoader}} वस्तु।{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} उदाहरण के लिए, {{java|StringBuilder.class.getClassLoader()}} लौटता है {{java|null}}.{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}}
बूटस्ट्रैप क्लास लोडर <code><JAVA_HOME>/jre/lib</code>  (या जावा 9 और उससे ऊपर के लिए  <code><JAVA_HOME>/jmods></code>) डायरेक्टरी में स्थित कोर जावा लाइब्रेरीज़<ref group=fn>These libraries are stored in [[JAR (file format)|Jar files]] called ''rt.jar'', ''core.jar'', ''server.jar'', etc.</ref> को लोड करता है। यह क्लास लोडर जो कोर जेवीएम का भाग है, मूल (नेटिव) कोड में लिखा गया है। बूस्ट्रैप {{java|ClassLoader}} किसी क्लासलोडर ऑब्जेक्ट से संबद्ध नहीं है।{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}} उदाहरण के लिए, {{java|StringBuilder.class.getClassLoader()}}रिटर्न्स {{java|null}}.{{sfn | Horstmann | 2022 | loc=§10.1.1 The Class-Loading Process}}


एक्सटेंशन क्लास लोडर एक्सटेंशन निर्देशिकाओं में कोड लोड करता है (<code><JAVA_HOME>/jre/lib/ext</code>,<ref name="TJT:UECL"/>या कोई अन्य निर्दिष्ट निर्देशिका
एक्सटेंशन क्लास लोडर एक्सटेंशन डायरेक्टरी (<code><JAVA_HOME>/jre/lib/ext</code>,<ref name="TJT:UECL"/>या <code>java.ext.dirs</code>सिस्टम प्रॉपर्टी द्वारा निर्दिष्ट किसी अन्य डायरेक्टरी) में कोड लोडिंग करता है।
से <code>java.ext.dirs</code> सिस्टम प्रॉपर्टी)


सिस्टम क्लास लोडर पर कोड लोड होता है <code>java.class.path</code>, जो मैप करता है <code>[[Classpath (Java)|CLASSPATH]]</code> [[पर्यावरणपरिवर्ती तारक]]
सिस्टम क्लास लोडर <code>java.class.path</code> पर पाए गए कोड का लोडिंग करता है, जो <code>[[Classpath (Java)|CLASSPATH]]</code> [[पर्यावरणपरिवर्ती तारक|एनवायरनमेंट]] वेरिएबल पर मैप होता है।


==उपयोगकर्ता-परिभाषित वर्ग लोडर==
==यूज़र डिफ़ाइंड क्लास लोडर==
जावा क्लास लोडर जावा में लिखा गया है। इसलिए जावा वर्चुअल मशीन की बारीकियों को समझे बिना अपना खुद का क्लास लोडर बनाना संभव है। बूटस्ट्रैप क्लास लोडर के अलावा, प्रत्येक जावा क्लास लोडर में एक पैरेंट क्लास लोडर होता है।{{sfn | Horstmann | 2022 | loc=10.1.2 The Class Loader Hierarchy}} पैरेंट क्लास लोडर को तब परिभाषित किया जाता है जब एक नए क्लास लोडर को इंस्टेंट किया जाता है या वर्चुअल मशीन के सिस्टम डिफॉल्ट क्लास लोडर पर सेट किया जाता है।
जावा क्लास लोडर जावा में लिखा गया है। इसलिए जावा वर्चुअल मशीन की विशेषताओं के ज्ञान के बिना, स्वयं के क्लास लोडर का निर्माण करना संभव है। बूटस्ट्रैप क्लास लोडर के अतिरिक्त प्रत्येक जावा क्लास लोडर में एक पैरेंट क्लास लोडर होता है।{{sfn | Horstmann | 2022 | loc=10.1.2 The Class Loader Hierarchy}} पैरेंट क्लास लोडर को उस स्थिति में परिभाषित किया जाता है जब एक नए क्लास लोडर को द्रिश्तान्किक्रित किया जाता है या वर्चुअल मशीन के सिस्टम डिफॉल्ट क्लास लोडर पर स्थित (सेट) किया जाता है।


इससे यह संभव हो जाता है (उदाहरण के लिए):
इससे यह संभव हो जाता है (उदाहरण के लिए):
* रनटाइम पर कक्षाओं को लोड या अनलोड करने के लिए (उदाहरण के लिए रनटाइम पर लाइब्रेरी को गतिशील रूप से लोड करना, यहां तक ​​कि [[ हाइपरटेक्स्ट परहस्त शिष्टाचार ]] संसाधन से भी)। यह इसके लिए एक महत्वपूर्ण विशेषता है:
* रनटाइम पर क्लासेस को लोड या अनलोड करने के लिए (उदाहरण के लिए [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |HTTP]] संसाधन से भी रनटाइम पर लाइब्रेरी को गतिशील रूप से लोड करना)। यह इसके लिए एक महत्वपूर्ण विशेषता है:
** ज्योथन जैसी स्क्रिप्टिंग भाषाओं को लागू करना
** ज्योथन जैसी स्क्रिप्टिंग लैंग्वेज को प्रयुक्त करना
** [[JavaBean]] बिल्डर्स का उपयोग करना
** [[JavaBean]] बिल्डर्स का उपयोग करना
** उपयोगकर्ता-परिभाषित विस्तारशीलता की अनुमति देना
** यूज़र डिफ़ाइंड एक्सटेंसिबिलिटी की अनुमति देना
** एकाधिक नामस्थानों को संचार करने की अनुमति देना। यह उदाहरण के लिए [[ सामान्य वस्तु अनुरोध ब्रोकर आर्किटेक्चर ]]/[[ जावा दूरस्थ विधि मंगलाचरण ]] प्रोटोकॉल की नींव में से एक है।
** एक से अधिक नेमस्पेस को सूचनाओं का आदान प्रदान करने की अनुमति देना। उदाहरण के लिए [[ सामान्य वस्तु अनुरोध ब्रोकर आर्किटेक्चर |CORBA]] / [[ जावा दूरस्थ विधि मंगलाचरण |RMI]] प्रोटोकॉल के मूल सिद्धांतों में से एक है।
* [[जावा बाइटकोड]] लोड करने के तरीके को बदलने के लिए (उदाहरण के लिए, [[ कूटलेखन ]] जावा क्लास बाइटकोड का उपयोग करना संभव है<ref>{{cite web
* [[जावा बाइटकोड]] लोड करने के तरीके को परिवर्तित करने के लिए (उदाहरण के लिए, एन्क्रिप्टेड जावा क्लास बाइटकोड का उपयोग करना संभव है)।<ref>{{cite web
  |last1=Roubtsov |first1=Vladimir
  |last1=Roubtsov |first1=Vladimir
  |date=2003-05-09 |df=mdy
  |date=2003-05-09 |df=mdy
Line 61: Line 60:
  |work=[[JavaWorld]]
  |work=[[JavaWorld]]
  |accessdate=2020-07-13
  |accessdate=2020-07-13
}}</ref>).
}}</ref>
* लोड किए गए बाइटकोड को संशोधित करने के लिए (उदाहरण के लिए, पहलू-उन्मुख प्रोग्रामिंग का उपयोग करते समय पहलुओं के लोड-टाइम [[पहलू बुनकर]] के लिए)।
* लोड किए गए बाइटकोड को संशोधित करने के लिए (उदाहरण के लिए, अस्पेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग करते समय अस्पेक्ट की लोड-टाइम व्यूति के लिए)।


== [[ जकार्ता ी | जकार्ता]] ईई में क्लास लोडर ==
== [[ जकार्ता ी | जकार्ता]] ईई में क्लास लोडर ==
Line 74: Line 73:
  |accessdate=2008-01-26
  |accessdate=2008-01-26
}}</ref>
}}</ref>
== जार नरक ==
== जार हेल ==
जेएआर हेल [[डीएलएल नरक]] के समान एक शब्द है जिसका उपयोग उन सभी विभिन्न तरीकों का वर्णन करने के लिए किया जाता है जिनमें क्लासलोडिंग प्रक्रिया काम नहीं कर सकती है।<ref>{{Cite web|url=http://incubator.apache.org/depot/version/jar-hell.html|archive-url = https://web.archive.org/web/20130601002059/http://incubator.apache.org/depot/version/jar-hell.html|archive-date = 2013-06-01|title = Depot - Apache Incubator}}</ref> तीन तरीके से JAR नरक घटित हो सकता है:
जार हेल [[डीएलएल नरक|डीएलएल हेल]] के समान एक शब्द है जिसका उपयोग उन सभी विभिन्न प्रकारों का वर्णन करने के लिए किया जाता है जिनमें क्लासलोडिंग प्रक्रिया कार्य नहीं कर सकती है।<ref>{{Cite web|url=http://incubator.apache.org/depot/version/jar-hell.html|archive-url = https://web.archive.org/web/20130601002059/http://incubator.apache.org/depot/version/jar-hell.html|archive-date = 2013-06-01|title = Depot - Apache Incubator}}</ref> तीन प्रकार से जार हेल उत्पन्न हो सकता है:
* सिस्टम पर स्थापित लाइब्रेरी के दो अलग-अलग संस्करणों की आकस्मिक उपस्थिति। इसे सिस्टम द्वारा त्रुटि नहीं माना जाएगा. बल्कि, सिस्टम किसी न किसी लाइब्रेरी से कक्षाएं लोड करेगा। नई लाइब्रेरी को प्रतिस्थापित करने के बजाय उपलब्ध लाइब्रेरी की सूची में जोड़ने से हो सकता है कि एप्लिकेशन अभी भी ऐसा व्यवहार कर रहा हो जैसे कि पुरानी लाइब्रेरी उपयोग में है, जो कि हो भी सकती है।
* किसी सिस्टम पर संस्थापित (इन्सटाल्ड) लाइब्रेरी के दो भिन्न-भिन्न संस्करणों (वर्शन) की आकस्मिक उपस्थिति। इसे सिस्टम द्वारा त्रुटि नहीं माना जाएगा। अपितु, सिस्टम किसी न किसी लाइब्रेरी से क्लासेस लोड करेगा। नई लाइब्रेरी को प्रतिस्थापित करने के स्थान पर उसे उपलब्ध लाइब्रेरी की सूची में संबद्ध करने से हो सकता है कि एप्लिकेशन अभी भी ऐसा व्यवहार कर रहा हो जैसे कि पुरानी लाइब्रेरी उपयोग में है जो कि हो भी सकती है।
* एकाधिक लाइब्रेरी या एप्लिकेशन को लाइब्रेरी फू के विभिन्न संस्करणों की आवश्यकता होती है। यदि लाइब्रेरी फू के संस्करण समान क्लास नामों का उपयोग करते हैं, तो लाइब्रेरी फू के संस्करणों को उसी क्लास लोडर के साथ लोड करने का कोई तरीका नहीं है।
* एक से अधिक लाइब्रेरी या एप्लिकेशन को लाइब्रेरी फू के विभिन्न संस्करणों की आवश्यकता होती है। यदि लाइब्रेरी फू के संस्करण समान क्लास नामों का उपयोग करते हैं तो लाइब्रेरी फू के संस्करणों को उसी क्लास लोडर के साथ लोड करने का कोई अन्य उपाय नहीं है।
* सबसे जटिल JAR नरक समस्याएँ उन परिस्थितियों में उत्पन्न होती हैं जो क्लासलोडिंग सिस्टम की पूर्ण जटिलता का लाभ उठाती हैं। एक जावा प्रोग्राम को केवल एक फ्लैट क्लास लोडर का उपयोग करने की आवश्यकता नहीं है, बल्कि इसके बजाय कई (संभवतः बहुत सारे) नेस्टेड, सहयोगी क्लास लोडर से बना हो सकता है। विभिन्न क्लास लोडर द्वारा लोड की गई कक्षाएं जटिल तरीकों से इंटरैक्ट कर सकती हैं जो किसी डेवलपर द्वारा पूरी तरह से समझ में नहीं आती हैं, जिससे त्रुटियां या बग होते हैं जिनका विश्लेषण, व्याख्या और समाधान करना मुश्किल होता है।<ref>{{Cite web|url=http://articles.qos.ch/classloader.html|title=Taxonomy of class loader problems with Jakarta Commons Logging}}</ref>
* अत्यधिक जटिल JAR हेल की समस्याएँ उन परिस्थितियों में उत्पन्न होती हैं जो क्लासलोडिंग सिस्टम की पूर्ण जटिलता का लाभ उठाती हैं। एक जावा प्रोग्राम के लिए केवल एक "फ्लैट" क्लास लोडर का उपयोग करना आवश्यक नहीं है, अपितु इसमें अनेक (संभवतः बहुत अधिक) नेस्टेड, सहयोगी क्लास लोडर समाहित हो सकते है। विभिन्न क्लास लोडर द्वारा लोड की गई क्लासेस जटिल प्रकारों से एक दूसरे को प्रभावित कर सकती हैं जो किसी डेवलपर द्वारा पूर्णतया समझ में नहीं आती हैं, जिससे त्रुटियां या बग उत्पन्न होते हैं तथा जिनको एनालाइज, एक्सप्लेन तथा रिसॉल्व करना कठिन होता है।<ref>{{Cite web|url=http://articles.qos.ch/classloader.html|title=Taxonomy of class loader problems with Jakarta Commons Logging}}</ref>
[[ओएसजीआई]] एलायंस ने निर्दिष्ट किया (1998 में जेएसआर 8 के रूप में शुरू) एक मॉड्यूलरिटी ढांचा जिसका उद्देश्य एमई, एसई और ईई में वर्तमान और भविष्य के वीएम के लिए जेएआर नरक को हल करना है जिसे व्यापक रूप से अपनाया गया है। JAR [[प्रकट फ़ाइल]] में मेटाडेटा का उपयोग करके, JAR फ़ाइलें (जिन्हें बंडल कहा जाता है) प्रति-पैकेज के आधार पर वायर्ड की जाती हैं। बंडल पैकेज निर्यात कर सकते हैं, पैकेज आयात कर सकते हैं और पैकेज को निजी रख सकते हैं, मॉड्यूलरिटी और संस्करण निर्भरता प्रबंधन की बुनियादी संरचनाएं प्रदान कर सकते हैं।
[[ओएसजीआई]] ने निर्दिष्ट किया (वर्ष 1998 में जेएसआर 8 के रूप में प्रारम्भ) एक मॉड्यूलरिटी संरचना जिसका उद्देश्य एमई, एसई और ईई में वर्तमान और भविष्य के वीएम के लिए जेएआर हेल का समाधान करना है जिसे व्यापक रूप से अपनाया गया है। JAR अभिव्यक्ति (मेनिफेस्ट) में मेटाडेटा का उपयोग करके JAR फ़ाइलें (जिन्हें बंडल कहा जाता है) को प्रति-पैकेज के आधार पर युग्मित किया जाता है। बंडल पैकेज का निर्यात और आयात कर सकते हैं तथा मॉड्यूलरिटी और संस्करण निर्भरता प्रबंधन की मूलभूत संरचनाएं प्रदान करके पैकेज को व्यक्तिगत रख सकते हैं।


JAR नरक समस्याओं को हल करने के लिए, एक जावा सामुदायिक प्रक्रिया - JSR 277 को 2005 में शुरू किया गया था। संकल्प - [[जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम]] - का उद्देश्य एक नया वितरण प्रारूप, एक मॉड्यूल संस्करण योजना और एक सामान्य मॉड्यूल रिपॉजिटरी (उद्देश्य के समान) पेश करना था माइक्रोसॉफ्ट .NET का [[ग्लोबल असेंबली कैश]])दिसंबर 2008 में, सन ने घोषणा की कि JSR 277 को रोक दिया गया है।<ref>{{cite web
JAR हेल समस्याओं को हल करने के लिए, वर्ष 2005 में एक जावा सामुदायिक प्रक्रिया - JSR 277 प्रारम्भ की गई थी। रिज़ॉल्यूशन - [[जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम]] - का उद्देश्य एक नया वितरण प्रारूप, एक मॉड्यूल संस्करण योजना और एक सामान्य मॉड्यूल रिपॉजिटरी (माइक्रोसॉफ्ट .NET के [[ग्लोबल असेंबली कैश]] के उद्देश्य के समान) प्रस्तुत करना है। दिसंबर वर्ष 2008 में सन ने घोषणा की कि JSR 277 को रोक दिया गया है।<ref>{{cite web
  |url=https://blogs.oracle.com/mr/entry/jigsaw
  |url=https://blogs.oracle.com/mr/entry/jigsaw
  |title=Project Jigsaw
  |title=Project Jigsaw
Line 90: Line 89:
  |archive-date=2015-12-08
  |archive-date=2015-12-08
  |url-status=dead
  |url-status=dead
}}</ref> जावा मॉड्यूल सिस्टम को बाद में प्रोजेक्ट आरा के रूप में रीबूट किया गया<ref>{{cite web
}}</ref> जावा मॉड्यूल सिस्टम को बाद में "प्रोजेक्ट जिग्सॉ"<ref>{{cite web
  |url=http://openjdk.java.net/projects/jigsaw/
  |url=http://openjdk.java.net/projects/jigsaw/
  |title=Project Jigsaw
  |title=Project Jigsaw
  |publisher=[[Oracle Corporation]]
  |publisher=[[Oracle Corporation]]
  |accessdate=2015-11-29
  |accessdate=2015-11-29
}}</ref> जिसे जावा संस्करण इतिहास#जावा एसई 9 में शामिल किया गया था। 2017 में जारी, इसमें मॉड्यूलर सॉफ़्टवेयर के लिए समर्थन शामिल है, जिसे जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम कहा जाता है, जिसे मॉड्यूल-info.java फ़ाइलों के साथ स्रोत स्तर पर नियंत्रित किया जाता है। यह ओएसजीआई आर्किटेक्चर से एक अलग दर्शन का पालन करता है जिसका उद्देश्य जावा रनटाइम पर्यावरण के लिए बैकवर्ड-संगत तरीके से मॉड्यूलरिटी प्रदान करना है जो जेआरई द्वारा प्रदान की जाने वाली लोडिंग कक्षाओं के डिफ़ॉल्ट तंत्र का उपयोग करता है। हालाँकि, चूंकि यह विभिन्न संस्करणों के साथ पुस्तकालयों के नियंत्रित सह-अस्तित्व की क्षमता प्रदान नहीं करता है, इसलिए यह JAR नरक समस्या से निपटने के लिए उपयुक्त नहीं है।<ref>{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1)
}}</ref> के रूप में रीबूट किया गया, जिसे जावा 9 में सम्मिलित किया गया था। वर्ष 2017 में विमोचित, इसमें "जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम" नामक मॉड्यूलर सॉफ़्टवेयर के लिए समर्थन सम्मिलित है जिसे मॉड्यूल-info.java फ़ाइलों के साथ सोर्स लेवल पर नियंत्रित किया जाता है। यह ओएसजीआई आर्किटेक्चर से एक भिन्न सिद्धांत का पालन करता है जिसका उद्देश्य जावा रनटाइम एनवायरनमेंट के लिए बैकवर्ड-कम्पटीएबेल मॉड्यूलरिटी प्रदान करना है जो जेआरई द्वारा प्रदान की जाने वाली लोडिंग क्लासेस के डिफ़ॉल्ट प्रक्रिया का उपयोग करता है। हालाँकि, चूंकि यह विभिन्न संस्करणों के साथ लाइब्रेरीज़ के नियंत्रित सह-उपस्थिति की क्षमता प्रदान नहीं करता है, इसलिए यह JAR हेल की समस्या से निपटने के लिए उपयुक्त नहीं है।<ref>{{cite web|first1=Neil|last1=Bartlett|first2=Kai|last2=Hackbarth|title=Java 9, OSGi and the Future of Modularity (Part 1)
|url=https://www.infoq.com/articles/java9-osgi-future-modularity/#1|publisher=InfoQ|date=2016-09-22}}</ref>
|url=https://www.infoq.com/articles/java9-osgi-future-modularity/#1|publisher=InfoQ|date=2016-09-22}}</ref>
==यह भी देखें==
==यह भी देखें==
* [[लोडर (कंप्यूटिंग)]]
* [[लोडर (कंप्यूटिंग)]]
* गतिशील लोडिंग
* डाइनामिक लोडिंग
* डीएलएल नरक
* डीएलएल हेल
* ओएसजीआई
* ओएसजीआई
* [[क्लासपाथ (जावा)]]
* [[क्लासपाथ (जावा)]]
Line 124: Line 121:
* Christoph G. Jung, "[https://web.archive.org/web/20130201093532/http://www.roseindia.net/javatutorials/hotdeploy.shtml Classloaders Revisited Hotdeploy]", ''Java Specialist Newsletter'', 2001-06-07
* Christoph G. Jung, "[https://web.archive.org/web/20130201093532/http://www.roseindia.net/javatutorials/hotdeploy.shtml Classloaders Revisited Hotdeploy]", ''Java Specialist Newsletter'', 2001-06-07
* Don Schwarz, "[https://web.archive.org/web/20180506083919/http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Managing Component Dependencies Using ClassLoaders]", 2005-04-13
* Don Schwarz, "[https://web.archive.org/web/20180506083919/http://www.onjava.com/pub/a/onjava/2005/04/13/dependencies.html Managing Component Dependencies Using ClassLoaders]", 2005-04-13
[[Category: जावा (प्रोग्रामिंग भाषा)]]


[[Category: Machine Translated Page]]
[[Category:Articles with example Java code]]
[[Category:Created On 11/07/2023]]
[[Category:Created On 11/07/2023]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Webarchive template wayback links]]
[[Category:जावा (प्रोग्रामिंग भाषा)]]

Latest revision as of 10:45, 27 July 2023

जावा क्लास लोडर जावा रनटाइम एनवायरनमेंट का एक भाग है जो जावा क्लास को जावा वर्चुअल मशीन में डाइनामिकाली लोड करता है।[1] सामान्यतः क्लासेस केवल अनुरोध पर ही लोड की जाती हैं। वर्चुअल मशीन केवल प्रोग्राम को निष्पादित करने के लिए आवश्यक क्लास फ़ाइल को लोड करेगी।[2] जावा रन टाइम सिस्टम को फ़ाइल और फ़ाइल सिस्टम के विषय में परिचित होने की आवश्यकता नहीं है क्योंकि यह क्लास लोडर को प्रत्यायोजित किया गया है।

एक सॉफ़्टवेयर लाइब्रेरी (कंप्यूटिंग) संबंधित ऑब्जेक्ट कोड का एक संग्रह है। जावा (प्रोग्रामिंग लैंग्वेज) में, लाइब्रेरीज़ को सामान्यतः JAR फ़ाइलों में पैक किया जाता है। लाइब्रेरी में विभिन्न प्रकार के ऑब्जेक्ट हो सकते हैं। जार फ़ाइल में सम्मिलित ऑब्जेक्ट का अधिक महत्वपूर्ण प्रकार जावा क्लास है। एक क्लास को यूनिट ऑफ़ कोड के रूप में विचारा जा सकता है। क्लास लोडर लाइब्रेरी का स्थान निर्धारण, उनकी विषय सूची का अध्ययन तथा लाइब्रेरी के भीतर उपस्थित क्लासेस को लोड करने के लिए उत्तरदायी है। यह लोडिंग सामान्यतः "ऑन डिमांड" की जाती है, ऐसा तब तक नहीं होता है जब तक प्रोग्राम द्वारा क्लास को कॉल नहीं किया जाता है। किसी नामित क्लास को दिए गए क्लास लोडर द्वारा केवल एक बार लोड किया जा सकता है।

प्रत्येक जावा क्लास को क्लास लोडर द्वारा ही लोड किया जाना चाहिए।[3][4] इसके अतिरिक्त, जावा (सॉफ़्टवेयर प्लेटफ़ॉर्म) एक्सटर्नल लाइब्रेरी का उपयोग कर सकते हैं (अर्थात, प्रोग्रामर के अतिरिक्त किसी अन्य द्वारा लिखित और प्रदान की गई लाइब्रेरी) या सम्भवतः उन्हें अनेक लाइब्रेरी के भागों में निर्माण किया जा सकता है।

जब JVM प्रारंभ किया जाता है, तो तीन क्लास लोडर का उपयोग किया जाता है:[5][6][2]

  1. बूटस्ट्रैप क्लास लोडर
  2. एक्सटेंशन क्लास लोडर
  3. सिस्टम क्लास लोडर

बूटस्ट्रैप क्लास लोडर <JAVA_HOME>/jre/lib (या जावा 9 और उससे ऊपर के लिए <JAVA_HOME>/jmods>) डायरेक्टरी में स्थित कोर जावा लाइब्रेरीज़[fn 1] को लोड करता है। यह क्लास लोडर जो कोर जेवीएम का भाग है, मूल (नेटिव) कोड में लिखा गया है। बूस्ट्रैप ClassLoader किसी क्लासलोडर ऑब्जेक्ट से संबद्ध नहीं है।[2] उदाहरण के लिए, StringBuilder.class.getClassLoader()रिटर्न्स null.[2]

एक्सटेंशन क्लास लोडर एक्सटेंशन डायरेक्टरी (<JAVA_HOME>/jre/lib/ext,[5]या java.ext.dirsसिस्टम प्रॉपर्टी द्वारा निर्दिष्ट किसी अन्य डायरेक्टरी) में कोड लोडिंग करता है।

सिस्टम क्लास लोडर java.class.path पर पाए गए कोड का लोडिंग करता है, जो CLASSPATH एनवायरनमेंट वेरिएबल पर मैप होता है।

यूज़र डिफ़ाइंड क्लास लोडर

जावा क्लास लोडर जावा में लिखा गया है। इसलिए जावा वर्चुअल मशीन की विशेषताओं के ज्ञान के बिना, स्वयं के क्लास लोडर का निर्माण करना संभव है। बूटस्ट्रैप क्लास लोडर के अतिरिक्त प्रत्येक जावा क्लास लोडर में एक पैरेंट क्लास लोडर होता है।[7] पैरेंट क्लास लोडर को उस स्थिति में परिभाषित किया जाता है जब एक नए क्लास लोडर को द्रिश्तान्किक्रित किया जाता है या वर्चुअल मशीन के सिस्टम डिफॉल्ट क्लास लोडर पर स्थित (सेट) किया जाता है।

इससे यह संभव हो जाता है (उदाहरण के लिए):

  • रनटाइम पर क्लासेस को लोड या अनलोड करने के लिए (उदाहरण के लिए HTTP संसाधन से भी रनटाइम पर लाइब्रेरी को गतिशील रूप से लोड करना)। यह इसके लिए एक महत्वपूर्ण विशेषता है:
    • ज्योथन जैसी स्क्रिप्टिंग लैंग्वेज को प्रयुक्त करना
    • JavaBean बिल्डर्स का उपयोग करना
    • यूज़र डिफ़ाइंड एक्सटेंसिबिलिटी की अनुमति देना
    • एक से अधिक नेमस्पेस को सूचनाओं का आदान प्रदान करने की अनुमति देना। उदाहरण के लिए CORBA / RMI प्रोटोकॉल के मूल सिद्धांतों में से एक है।
  • जावा बाइटकोड लोड करने के तरीके को परिवर्तित करने के लिए (उदाहरण के लिए, एन्क्रिप्टेड जावा क्लास बाइटकोड का उपयोग करना संभव है)।[8]
  • लोड किए गए बाइटकोड को संशोधित करने के लिए (उदाहरण के लिए, अस्पेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग करते समय अस्पेक्ट की लोड-टाइम व्यूति के लिए)।

जकार्ता ईई में क्लास लोडर

जकार्ता ईई (पूर्व में जावा ईई और जे2ईई) एप्लिकेशन सर्वर सामान्यतः क्लास लोडर के एक ट्री द्वारा परिनियोजित डब्ल्यूएआर (फ़ाइल प्रारूप) या ईएआर (फ़ाइल प्रारूप) संग्रह से क्लासेस लोड करते हैं जो एप्लिकेशन को अन्य अनुप्रयोगों से पृथक करते हैं किन्तु परिनियोजित मॉड्यूल के मध्य क्लासेस साझा करते हैं। तथाकथित सर्वलेट कंटेनर सामान्यतः एक से अधिक क्लास लोडर के संबंध में कार्यान्वित किए जाते हैं।[4][9]

जार हेल

जार हेल डीएलएल हेल के समान एक शब्द है जिसका उपयोग उन सभी विभिन्न प्रकारों का वर्णन करने के लिए किया जाता है जिनमें क्लासलोडिंग प्रक्रिया कार्य नहीं कर सकती है।[10] तीन प्रकार से जार हेल उत्पन्न हो सकता है:

  • किसी सिस्टम पर संस्थापित (इन्सटाल्ड) लाइब्रेरी के दो भिन्न-भिन्न संस्करणों (वर्शन) की आकस्मिक उपस्थिति। इसे सिस्टम द्वारा त्रुटि नहीं माना जाएगा। अपितु, सिस्टम किसी न किसी लाइब्रेरी से क्लासेस लोड करेगा। नई लाइब्रेरी को प्रतिस्थापित करने के स्थान पर उसे उपलब्ध लाइब्रेरी की सूची में संबद्ध करने से हो सकता है कि एप्लिकेशन अभी भी ऐसा व्यवहार कर रहा हो जैसे कि पुरानी लाइब्रेरी उपयोग में है जो कि हो भी सकती है।
  • एक से अधिक लाइब्रेरी या एप्लिकेशन को लाइब्रेरी फू के विभिन्न संस्करणों की आवश्यकता होती है। यदि लाइब्रेरी फू के संस्करण समान क्लास नामों का उपयोग करते हैं तो लाइब्रेरी फू के संस्करणों को उसी क्लास लोडर के साथ लोड करने का कोई अन्य उपाय नहीं है।
  • अत्यधिक जटिल JAR हेल की समस्याएँ उन परिस्थितियों में उत्पन्न होती हैं जो क्लासलोडिंग सिस्टम की पूर्ण जटिलता का लाभ उठाती हैं। एक जावा प्रोग्राम के लिए केवल एक "फ्लैट" क्लास लोडर का उपयोग करना आवश्यक नहीं है, अपितु इसमें अनेक (संभवतः बहुत अधिक) नेस्टेड, सहयोगी क्लास लोडर समाहित हो सकते है। विभिन्न क्लास लोडर द्वारा लोड की गई क्लासेस जटिल प्रकारों से एक दूसरे को प्रभावित कर सकती हैं जो किसी डेवलपर द्वारा पूर्णतया समझ में नहीं आती हैं, जिससे त्रुटियां या बग उत्पन्न होते हैं तथा जिनको एनालाइज, एक्सप्लेन तथा रिसॉल्व करना कठिन होता है।[11]

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

JAR हेल समस्याओं को हल करने के लिए, वर्ष 2005 में एक जावा सामुदायिक प्रक्रिया - JSR 277 प्रारम्भ की गई थी। रिज़ॉल्यूशन - जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम - का उद्देश्य एक नया वितरण प्रारूप, एक मॉड्यूल संस्करण योजना और एक सामान्य मॉड्यूल रिपॉजिटरी (माइक्रोसॉफ्ट .NET के ग्लोबल असेंबली कैश के उद्देश्य के समान) प्रस्तुत करना है। दिसंबर वर्ष 2008 में सन ने घोषणा की कि JSR 277 को रोक दिया गया है।[12] जावा मॉड्यूल सिस्टम को बाद में "प्रोजेक्ट जिग्सॉ"[13] के रूप में रीबूट किया गया, जिसे जावा 9 में सम्मिलित किया गया था। वर्ष 2017 में विमोचित, इसमें "जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम" नामक मॉड्यूलर सॉफ़्टवेयर के लिए समर्थन सम्मिलित है जिसे मॉड्यूल-info.java फ़ाइलों के साथ सोर्स लेवल पर नियंत्रित किया जाता है। यह ओएसजीआई आर्किटेक्चर से एक भिन्न सिद्धांत का पालन करता है जिसका उद्देश्य जावा रनटाइम एनवायरनमेंट के लिए बैकवर्ड-कम्पटीएबेल मॉड्यूलरिटी प्रदान करना है जो जेआरई द्वारा प्रदान की जाने वाली लोडिंग क्लासेस के डिफ़ॉल्ट प्रक्रिया का उपयोग करता है। हालाँकि, चूंकि यह विभिन्न संस्करणों के साथ लाइब्रेरीज़ के नियंत्रित सह-उपस्थिति की क्षमता प्रदान नहीं करता है, इसलिए यह JAR हेल की समस्या से निपटने के लिए उपयुक्त नहीं है।[14]

यह भी देखें

फ़ुटनोट

  1. These libraries are stored in Jar files called rt.jar, core.jar, server.jar, etc.

संदर्भ

  1. Mcmanis, Chuck (October 1, 1996). "The basics of Java class loaders". JavaWorld. Retrieved 2020-07-13.
  2. 2.0 2.1 2.2 2.3 Horstmann 2022, §10.1.1 The Class-Loading Process.
  3. Horstmann 2022, §8.2.5 Writing Byte Codes to Memory.
  4. 4.0 4.1 Christudas, Binildas (January 26, 2005). "Internals of Java Class Loading". onjava.com. Archived from the original on 2018-05-10.
  5. 5.0 5.1 "Understanding Extension Class Loading". The Java Tutorials. docs.oracle.com. Retrieved 2020-07-13.
  6. Sosnoski, Dennis (April 29, 2003). "Classes and class loading". IBM DeveloperWorks. Retrieved 2008-01-26.
  7. Horstmann 2022, 10.1.2 The Class Loader Hierarchy.
  8. Roubtsov, Vladimir (May 9, 2003). "Cracking Java byte-code encryption". JavaWorld. Retrieved 2020-07-13.
  9. deBoer, Tim; Karasiuk, Gary (August 21, 2002). "J2EE Class Loading Demystified". IBM DeveloperWorks. Retrieved 2008-01-26.
  10. "Depot - Apache Incubator". Archived from the original on 2013-06-01.
  11. "Taxonomy of class loader problems with Jakarta Commons Logging".
  12. Mark Reinhold (September 20, 2010). "Project Jigsaw". Oracle Corporation. Archived from the original on 2015-12-08.
  13. "Project Jigsaw". Oracle Corporation. Retrieved 2015-11-29.
  14. Bartlett, Neil; Hackbarth, Kai (2016-09-22). "Java 9, OSGi and the Future of Modularity (Part 1)". InfoQ.


बाहरी संबंध