जावा क्लासलोडर

जावा क्लास लोडर जावा क्रम पर्यावरण का एक हिस्सा है जो जावा क्लास को जावा वर्चुअल मशीन में गतिशील लोडिंग करता है। आमतौर पर कक्षाएं केवल आलसी आरंभीकरण से भरी होती हैं। वर्चुअल मशीन केवल प्रोग्राम को निष्पादित करने के लिए आवश्यक क्लास फ़ाइलों को लोड करेगी। जावा रन टाइम सिस्टम को फाइलों और फाइल सिस्टम के बारे में जानने की जरूरत नहीं है क्योंकि यह क्लास लोडर को डेलिगेशन _(ऑब्जेक्ट-ओरिएंटेड_प्रोग्रामिंग) है।

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

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

जब JVM प्रारंभ किया जाता है, तो तीन क्लास लोडर का उपयोग किया जाता है:
 * 1) बूटस्ट्रैप क्लास लोडर
 * 2) एक्सटेंशन क्लास लोडर
 * 3) सिस्टम क्लास लोडर

बूटस्ट्रैप क्लास लोडर कोर जावा लाइब्रेरीज़ को लोड करता है में स्थित  (या   जावा 9 और उससे ऊपर के लिए) निर्देशिका। यह क्लास लोडर, जो कोर जेवीएम का हिस्सा है, मूल कोड में लिखा गया है। बूस्ट्रैप क्लास लोडर किसी से संबद्ध नहीं है  वस्तु। उदाहरण के लिए,  लौटता है.

एक्सटेंशन क्लास लोडर एक्सटेंशन निर्देशिकाओं में कोड लोड करता है (, या कोई अन्य निर्दिष्ट निर्देशिका से  सिस्टम प्रॉपर्टी)।

सिस्टम क्लास लोडर पर कोड लोड होता है, जो मैप करता है   पर्यावरणपरिवर्ती तारक।

उपयोगकर्ता-परिभाषित वर्ग लोडर
जावा क्लास लोडर जावा में लिखा गया है। इसलिए जावा वर्चुअल मशीन की बारीकियों को समझे बिना अपना खुद का क्लास लोडर बनाना संभव है। बूटस्ट्रैप क्लास लोडर के अलावा, प्रत्येक जावा क्लास लोडर में एक पैरेंट क्लास लोडर होता है। पैरेंट क्लास लोडर को तब परिभाषित किया जाता है जब एक नए क्लास लोडर को इंस्टेंट किया जाता है या वर्चुअल मशीन के सिस्टम डिफॉल्ट क्लास लोडर पर सेट किया जाता है।

इससे यह संभव हो जाता है (उदाहरण के लिए):
 * रनटाइम पर कक्षाओं को लोड या अनलोड करने के लिए (उदाहरण के लिए रनटाइम पर लाइब्रेरी को गतिशील रूप से लोड करना, यहां तक ​​कि हाइपरटेक्स्ट परहस्त शिष्टाचार  संसाधन से भी)। यह इसके लिए एक महत्वपूर्ण विशेषता है:
 * ज्योथन जैसी स्क्रिप्टिंग भाषाओं को लागू करना
 * JavaBean बिल्डर्स का उपयोग करना
 * उपयोगकर्ता-परिभाषित विस्तारशीलता की अनुमति देना
 * एकाधिक नामस्थानों को संचार करने की अनुमति देना। यह उदाहरण के लिए सामान्य वस्तु अनुरोध ब्रोकर आर्किटेक्चर / जावा दूरस्थ विधि मंगलाचरण  प्रोटोकॉल की नींव में से एक है।
 * जावा बाइटकोड लोड करने के तरीके को बदलने के लिए (उदाहरण के लिए, कूटलेखन  जावा क्लास बाइटकोड का उपयोग करना संभव है ).
 * लोड किए गए बाइटकोड को संशोधित करने के लिए (उदाहरण के लिए, पहलू-उन्मुख प्रोग्रामिंग का उपयोग करते समय पहलुओं के लोड-टाइम पहलू बुनकर के लिए)।

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

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

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

यह भी देखें

 * लोडर (कंप्यूटिंग)
 * गतिशील लोडिंग
 * डीएलएल नरक
 * ओएसजीआई
 * क्लासपाथ (जावा)
 * जावा प्लेटफ़ॉर्म मॉड्यूल सिस्टम

बाहरी संबंध

 * Chuck McManis, "The basics of Java class loaders", 1996
 * Brandon E. Taylor, "Java Class Loading: The Basics ", 2003
 * Jeff Hanson, "Take Control of Class Loading in Java ", 2006-06-01
 * Andreas Schaefer, "Inside Class Loaders", 2003-11-12
 * Sheng Liang and Gilad Bracha, "Dynamic class loading in the Java virtual machine", In Proceedings of the 13th ACM Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA'98), ACM SIGPLAN Notices, vol. 33, no. 10, ACM Press, 1998, pp. 36–44
 * Jeremy Whitlock, "Real-World Use For Custom ClassLoaders", May 2005
 * Christoph G. Jung, "Classloaders Revisited Hotdeploy", Java Specialist Newsletter, 2001-06-07
 * Don Schwarz, "Managing Component Dependencies Using ClassLoaders", 2005-04-13
 * Don Schwarz, "Managing Component Dependencies Using ClassLoaders", 2005-04-13