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

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

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

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

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

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

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

सिस्टम क्लास लोडर पर पाए गए कोड का भारण करता है, जो    एनवायरनमेंट चर पर प्रतिचित्रित होता है।

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

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

जकार्ता ईई में क्लास लोडर
जकार्ता ईई (पूर्व में जावा ईई और जे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