🤷🏻 🚵 🌘 जावा एप्लिकेशन का उपयोग करने वाले सभी वर्गों को परिभाषित करें। 💒 👆🏻 💃🏿

बिना किसी संदेह के, जो हर कोई अपने जीवन में कम से कम एक बार रेखाओं में जावा विकास के अनुभव को इंगित करता है

public static void main(String[] args)

उन्हें संकलित किया और उन्हें java HelloWorld जैसी कमांड के साथ लॉन्च किया।
लेकिन कितने लोग जानते हैं कि जेवीएम के भीतर उस समय से क्या होता है जब तक इस कमांड को निष्पादित नहीं किया जाता है जब तक कि नियंत्रण मुख्य विधि से पारित नहीं हो जाता है, जावा उपयोगकर्ता के लिए आवश्यक कक्षाएं कैसे ढूंढता है और लोड करता है? एक बार उत्पन्न होने वाले उत्पादन कार्य ने लेखक को इस तरह से अलग कर दिया। बिल्ली के तहत सर्वेक्षण के परिणाम। यह ध्यान देने योग्य है कि लेख सभी मौजूदा JVM को कवर करने का ढोंग नहीं करता है, परीक्षण केवल Sun HotSpot JVM पर आयोजित किया गया था।

समस्या का बयान

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

सिस्टम क्लास लोडर को ओवरराइड करना

इस समस्या को हल करते समय जो पहली दिशा दिमाग में आई, वह थी जावा में क्लास लोडिंग मैकेनिज्म के विस्तार का लाभ उठाना। इस विषय पर बहुत सारे लेख लिखे गए हैं, जिनमें रूसी (लेख के अंत में लिंक) शामिल हैं।
इस तंत्र का सार इस प्रकार है:

अमूर्त वर्ग के वंशज java.lang.ClassLoader का उपयोग सीधे कक्षाओं को लोड करने के लिए किया जाता है, क्योंकि Class loadClass(String name) पद्धति के हस्ताक्षर द्वारा स्पष्ट रूप से गवाही दी जाती है। इस विधि को बाइट सरणी मिलनी चाहिए, जो वांछित वर्ग का protected Class defineClass(String name, byte[] b, int off, int len) , और इसे protected Class defineClass(String name, byte[] b, int off, int len) पद्धति से पास करें, जो इसे java.lang.Class वर्ग के उदाहरण में बदल देता है। इस प्रकार, अपने लोडरों को लागू करके, डेवलपर्स कहीं से भी डाउनलोड कर सकते हैं जहां आप बाइट्स की एक सरणी प्राप्त कर सकते हैं;
फ्रेमवर्क के डेवलपर्स लोडरों के पदानुक्रम और वंशानुक्रम के लिए एक मुश्किल तंत्र घोषित करते हैं। इसके अलावा, यहाँ विरासत को OOP में वर्ग की विरासत के संदर्भ में नहीं समझा जाना चाहिए, लेकिन ClassLoader क्लास के getParent विधि का उपयोग करके एक अलग पदानुक्रम के रूप में आयोजित किया जाता है। जेवीएम की शुरुआत में, इस पदानुक्रम का शीर्ष तीन मुख्य लोडर से बनाया गया है: आधार (बूटस्ट्रैप क्लास लोडर, ढांचे के आधार वर्गों को लोड करने के लिए ज़िम्मेदार), एक्सटेंशन लोडर (एक्सटेंशन क्लास लोडर, जो लिब / एक्स से लोडिंग कक्षाओं के लिए ज़िम्मेदार है) और सिस्टम लोडर (सिस्टम क्लास लोडर, लोडिंग के लिए ज़िम्मेदार है) कस्टम कक्षाएं)। इसके अलावा, डेवलपर्स इस पदानुक्रम को बूट लोडर और नीचे से जारी रखने के लिए स्वतंत्र हैं। डिफ़ॉल्ट रूप से, हॉटस्पॉट JVM में, sun.misc.Launcher$AppClassLoader वर्ग को सिस्टम लोडर के रूप में प्रयोग किया जाता है, हालाँकि, इसे java.system.class.loader प्रणाली की java.system.class.loader कमांड-लाइन java -Djava.system.class.loader=.. का उपयोग करके आसानी से ओवरराइड किया जा सकता है। java -Djava.system.class.loader=.. ;
डाउनलोड डाउनलोड करने का नियम घोषित किया गया है: किसी भी वर्ग को लोड करने से पहले, किसी भी लोडर को पहले अपने माता-पिता से संपर्क करना होगा, और केवल अगर वह जिस वर्ग की तलाश में है उसे लोड नहीं कर सकता है, तो उसे स्वयं लोड करने का प्रयास करें। दुर्भाग्य से, इस नियम की सुंदरता और सुविधा इसके कार्यान्वयन की गैर-बाध्यकारी प्रकृति से ऑफसेट हैं। इस नियम का पालन करने में विफलता के परिणामों के साथ, लेखक को अभी तक सामना करना पड़ा है।

हालांकि, इस स्तर पर, समस्या को हल करने के लिए पहली अवधारणा पहले ही दिखाई दे चुकी है:

सिस्टम को बदलने वाले अपने स्वयं के क्लास लोडर को लागू करें, जो लोडक्लास विधि को कॉल करते समय, बस क्लास का नाम एक फाइल में लिख देगा और क्लास को वास्तविक सिस्टम लोडर में लोड करने का अनुरोध भेजेगा। ऊपर वर्णित प्रतिनिधि नियम के अधीन, इससे सभी लोड किए गए उपयोगकर्ता वर्गों को पकड़ना संभव हो सकता है, भले ही वे अन्य लोडर द्वारा लोड किए गए हों;
इस क्लास लोडर को सिस्टम एक के रूप में उपयोग करने के लिए मशीन पर चलने वाले सभी JVM को बाध्य करें।

दूसरे पैराग्राफ को लागू करने के लिए, निम्नलिखित कार्यों को हल करना आवश्यक है:

सभी चलने वाले JVM को कक्षा को दृश्यमान बनाएं। सिस्टम विस्तार के दृष्टिकोण से कई एप्लिकेशन घटकों के सभी वर्गपथ में एक वर्ग को शामिल करने के लिए यह असुविधाजनक, समय लेने वाली और तर्कहीन है। इसके अलावा, एक और अधिक सुंदर समाधान है - लोडर वर्ग को lib / ext JRE फ़ोल्डर में डालें। इस फ़ोल्डर में कक्षाएं उन्हें कक्षापथ में प्रवेश किए बिना स्वचालित रूप से उपलब्ध हो जाती हैं (जैसा कि ऊपर उल्लेख किया गया है, वे जेवीएम शुरू होने पर एक्सटेंशन लोडर द्वारा लोड किए जाते हैं);
सभी java.system.class.loader लिए java.system.class.loader सिस्टम प्रॉपर्टी सेट करें - इसे इस तरह से कमांड लाइन से किया जा सकता है: java -Djava.system.class.loader=.. HelloWolrd
सीधे सभी जेवीएम को आवश्यक पैरामीटर के साथ शुरू करने के लिए मजबूर करें -Djava.system.class.loader । जैसा कि यह निकला, इसके लिए एक सुरुचिपूर्ण समाधान भी है - आपको एक विशेष पर्यावरण चर का उपयोग करने की आवश्यकता है, जिसका मूल्य स्वचालित रूप से किसी भी जेवीएम के स्टार्टअप मापदंडों में जोड़ा जाता है। खोज के दौरान, दो चर पाए गए जो इस सुविधा के लिए जिम्मेदार हो सकते हैं: JAVA_OPTS और JAVA_TOOL_OPTIONS। हालांकि, किसी भी लेख ने इस सवाल का स्पष्ट जवाब नहीं दिया: इन दो चर के बीच अंतर क्या है? इस प्रश्न का उत्तर अनुभवजन्य रूप से खोजने का निर्णय लिया गया था। प्रयोग के दौरान, यह पाया गया कि JAVA_TOOL_OPTIONS चर वास्तव में "जादू" है, जिसका मूल्य स्वचालित रूप से लॉन्च किए गए किसी भी हॉटस्पॉट JVM के स्टार्टअप मापदंडों में जोड़ा जाता है। और JAVA_OPTS विभिन्न जावा अनुप्रयोगों के डेवलपर्स के बीच एक मौन समझौते का परिणाम है। कई स्क्रिप्ट स्पष्ट रूप से इस चर का उपयोग करती हैं (उदाहरण के लिए, अपाचे टॉम्काट को लॉन्च करने के लिए स्टार्टअप.sh/startup.bat), लेकिन कोई भी गारंटी नहीं देता है कि सभी स्क्रिप्ट डेवलपर्स इस चर का उपयोग करेंगे।

तो, काम किया जाता है, लोडर को संकलित किया जाता है और उन्हें lib / ext में रखा जाता है, पर्यावरण चर JAVA_TOOL_OPTIONS का मान सेट किया जाता है, हम एप्लिकेशन लॉन्च करते हैं, काम करते हैं, लॉग खोलते हैं और देखते हैं ... सिस्टम और कई अन्य तृतीय-पक्ष कक्षाओं सहित एक दर्जन वर्गों की एक JAVA_TOOL_OPTIONS सूची। यह तब था जब मुझे डाउनलोड प्रतिनिधि नियम के वैकल्पिक कार्यान्वयन को याद करना था, साथ ही साथ अपाचे चींटी और टॉमकैट के स्रोत कोड को देखना था। जैसा कि यह निकला, ये एप्लिकेशन अपने स्वयं के क्लास लोडर का उपयोग करते हैं। यह, एक तरफ, आंशिक रूप से उन्हें अपनी शक्तिशाली कार्यक्षमता खोजने की अनुमति देता है। हालांकि, एक कारण या किसी अन्य के लिए, इन उत्पादों के डेवलपर्स ने डाउनलोड करने के लिए अनुशंसित नियम का पालन नहीं करने का फैसला किया, और उनके द्वारा लिखे गए लोडर हमेशा दूसरे वर्ग को लोड करने से पहले अपने माता-पिता से संपर्क नहीं करते हैं। यही कारण है कि हमारे सिस्टम लोडर टॉम्केट और चींटी द्वारा लोड की गई कक्षाओं के बारे में लगभग कुछ भी नहीं जानता है।
इस प्रकार, वर्णित विधि आपको सभी आवश्यक वर्गों को पकड़ने की अनुमति नहीं देती है, विशेष रूप से उपयोग किए जाने वाले विभिन्न प्रकार के एप्लिकेशन सर्वरों को दिया जाता है - जो यह जानते हैं कि एप्लिकेशन सर्वर के डेवलपर्स ने ग्राहक के प्रतिनिधिमंडल नियम का उपयोग कैसे किया है।

नंबर दो का प्रयास। क्लास इंस्ट्रूमेंटेशन लागू करें

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

byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer)

विधि

byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer)

ClassFileTransformer

byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer)

को ClassFileTransformer इंटरफ़ेस कहा जाता है। किसी भी वर्ग को लोड करना। यह पद्धति अड़चन बन गई जिसके माध्यम से कोई भी लोड करने योग्य वर्ग गुजरता है, बहुत कम संख्या में सिस्टम के अपवाद के साथ।
अब कार्य निम्नानुसार है:

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

ट्रांसफार्मर क्लास का स्रोत कोड नीचे प्रस्तुत किया गया है:

 package com.test; import java.io.File; import java.lang.instrument.Instrumentation; import java.lang.instrument.ClassFileTransformer; import java.security.ProtectionDomain; import java.lang.instrument.IllegalClassFormatException; public class LoggingClassFileTransformer implements ClassFileTransformer { public static void premain(String agentArguments, Instrumentation instrumentation) { instrumentation.addTransformer(new LoggingClassFileTransformer()); } /** *        * @param className        * @return  classfileBuffer  -  */ public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException { log(className); return classfileBuffer; } //     lib/ext private static final File logFile = new File(System.getProperty("java.ext.dirs").split(File.pathSeparator)[0]+"/LoggingClassFileTransformer.log"); public static synchronized void log(String text) { //    // ... } }

यहां वर्ग ट्रांसफार्मर का उपयोग करने के लिए तंत्र की व्याख्या करना आवश्यक है। इस तरह के वर्ग को एप्लिकेशन से जोड़ने के लिए, हमें तथाकथित प्रीमियर क्लास की आवश्यकता है, अर्थात्। public static void premain(String paramString, Instrumentation paramInstrumentation) युक्त एक वर्ग। यह उस विधि के नाम से स्पष्ट है जिसे इसे मुख्य विधि कहने से पहले कहा जाता है। इस बिंदु पर, आप ट्रांसफार्मर क्लासेस को addTransformer इंटरफ़ेस के addTransformer विधि का उपयोग करके एप्लिकेशन से कनेक्ट कर सकते हैं। इस प्रकार, उपरोक्त वर्ग ट्रांसफार्मर क्लास और प्रीमियर क्लास दोनों है। इस वर्ग का उपयोग करने के लिए, इसे एक JAR फ़ाइल में रखा जाना चाहिए, जिसके प्रकट होने पर (META-INF / MANIFEST.MF फ़ाइल) में Premain-Class पैरामीटर होता है जो प्रीमियर क्लास का पूरा नाम दर्शाता है, हमारे मामले में Premain-Class: com.test.LoggingClassFileTransformer । फिर आपको JVM शुरू करते समय -javaagent पैरामीटर का उपयोग करके इस संग्रह को पूर्ण पथ निर्दिष्ट करने की आवश्यकता है। यहाँ JAVA_TOOL_OPTIONS चर फिर से हमारी सहायता के लिए आता है।
तो, वर्ग JAR, पर्यावरण चर JAVA_TOOL_OPTIONS=-javaagent:" LoggingClassFileTransformer.jar" में प्रकट होने के साथ लिखा, संकलित, पैक किया गया है JAVA_TOOL_OPTIONS=-javaagent:" LoggingClassFileTransformer.jar" सेट है, अनुप्रयोग चल रहा है, लॉग संकलित है, PROFIT!
upd3।
हेब्रूसर ग्रॉस्वाइस ने इंस्ट्रूमेंटेशन का उपयोग करते हुए अभी तक एक और तरीका प्रस्तावित किया है - एस्पेक्टज: "यह प्रासंगिक है यदि आपको पर्यावरण को प्रभावित किए बिना अपने आवेदन में सभी वर्गों को सस्ता करने की आवश्यकता है, लेकिन यह थोड़ा अलग काम है।"

युपीडी।

तीसरा तरीका। स्क्रैप के रूप में सरल

हैब्रीजर स्पाइफ और अपांगिन के लिए धन्यवाद, जिन्होंने व्यक्तिगत रूप से एक और तरीके के बारे में याद दिलाया जो मैंने कोशिश की थी, लेकिन अवांछनीय रूप से भूल गया था, क्योंकि समाप्त नहीं हुआ।
यह विधि --XX:+TraceClassLoading -verbose:class या --XX:+TraceClassLoading साथ JVM को शुरू करने पर आधारित है। इन मापदंडों में से किसी का उपयोग करते समय, [Loaded java.util.Date from shared objects file] जैसे संदेश मानक JVM आउटपुट स्ट्रीम में डाले [Loaded java.util.Date from shared objects file] । हालांकि, यह विधि, इसकी सादगी के बावजूद, एक महत्वपूर्ण दोष है - आउटपुट संदेश के प्रारूप को नियंत्रित करना मुश्किल है, साथ ही साथ आउटपुट की दिशा भी। और प्रश्न में आवेदन पहले से ही स्टडआउट के लिए पर्याप्त डिबगिंग जानकारी को आउटपुट करता है, और इस स्ट्रीम से आवश्यक संदेशों को फ़िल्टर करने की क्षमता और सर्वर पर चल रहे सभी जेवीएम इंस्टेंसेस के लिए एक अलग फाइल पर उन्हें रीडायरेक्ट करता है।
upd2।
हब्रासर अपांगिन इस विधि को निम्नलिखित जेवीएम लॉन्च विकल्प में जोड़ा गया था:

java -XX:+TraceClassLoading -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=java_*.log -XX:-DisplayVMOutput HelloWorld

* के बजाय, पीआईडी स्वचालित रूप से प्रतिस्थापित किया गया है।
इस तरह के आदेश को चलाने के बाद, नाम के साथ एक फ़ाइल उत्पन्न होगी, उदाहरण के लिए, java_580.log, इस तरह से:

 <?xml version='1.0' encoding='UTF-8'?> <hotspot_log version='160 1' process='580' time_ms='1334248301214'> <vm_version> <name> Java HotSpot(TM) Client VM </name> <release> 20.6-b01 </release> <info> Java HotSpot(TM) Client VM (20.6-b01) for windows-x86 JRE (1.6.0_31-b05), built on Feb 3 2012 18:44:09 by "java_re" with MS VC++ 7.1 (VS2003) </info> </vm_version> <vm_arguments> <args> -XX:+TraceClassLoading -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=java_*.log -XX:-DisplayVMOutput </args> <command> test </command> <launcher> SUN_STANDARD </launcher> <properties> java.vm.specification.name=Java Virtual Machine Specification java.vm.version=20.6-b01 java.vm.name=Java HotSpot(TM) Client VM java.vm.info=mixed mode, sharing java.ext.dirs=C:\Program Files\Java\jre6\lib\ext;C:\WINDOWS\Sun\Java\lib\ext java.endorsed.dirs=C:\Program Files\Java\jre6\lib\endorsed sun.boot.library.path=C:\Program Files\Java\jre6\bin java.library.path=C:\WINDOWS\system32;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\PC Connectivity Solution\;C:\Program Files\Rockwell Software\RSCommon;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Java\jdk1.6.0_06\bin;c:\hibernate;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Nmap;;C:\PROGRA~1\COMMON~1\MUVEET~1\030625;C:\PROGRA~1\COMMON~1\MUVEET~1\030625;. java.home=C:\Program Files\Java\jre6 java.class.path=. sun.boot.class.path=C:\Program Files\Java\jre6\lib\resources.jar;C:\Program Files\Java\jre6\lib\rt.jar;C:\Program Files\Java\jre6\lib\sunrsasign.jar;C:\Program Files\Java\jre6\lib\jsse.jar;C:\Program Files\Java\jre6\lib\jce.jar;C:\Program Files\Java\jre6\lib\charsets.jar;C:\Program Files\Java\jre6\lib\modules\jdk.boot.jar;C:\Program Files\Java\jre6\classes java.vm.specification.vendor=Sun Microsystems Inc. java.vm.specification.version=1.0 java.vm.vendor=Sun Microsystems Inc. sun.java.command=test sun.java.launcher=SUN_STANDARD </properties> </vm_arguments> <tty> <writer thread='1504'/> [Loaded java.lang.Object from shared objects file] ... <writer thread='3092'/> <destroy_vm stamp='0.281'/> <tty_done stamp='0.283'/> </tty> <hotspot_log_done stamp='0.283'/> </hotspot_log>

इस मामले में, मानक आउटपुट स्ट्रीम पर कुछ भी नया नहीं लिखा गया है, धन्यवाद -XX:-DisplayVMOutput विकल्प।
इस पद्धति का मुख्य लाभ इसकी सादगी है। यह एक तथ्य नहीं है कि इस तरह का एक फ़ाइल प्रारूप ग्राहक के अनुरूप होगा, लेकिन यह पहले से ही एक बहस का मुद्दा है और यह इस लेख के दायरे में शामिल नहीं है।

निष्कर्ष

इसलिए, परियोजना पर काम खत्म करने के बाद क्या निष्कर्ष निकाला जा सकता है:

जावा में लोडिंग कक्षाओं के लिए तंत्र फ्रेमवर्क की एक दिलचस्प और बहुत ही उपयोगी विशेषता है, जो समस्याओं की एक निश्चित श्रृंखला को हल करने के लिए उपयोगी हो सकता है। हालांकि, यह याद रखने योग्य है कि इस तंत्र का उपयोग करके हल किया जा सकने वाला मुख्य कार्य कक्षा को ऐसी जगह से ढूंढना और लोड करना है जहां अन्य इसे लोड कर सकते हैं। भरी हुई कक्षाओं के बारे में जानकारी एकत्र करने के लिए, यह तंत्र बहुत काम का हो सकता है;
जावा में क्लास इंस्ट्रूमेंटेशन कक्षाओं के साथ काम करने के लिए एक और शक्तिशाली तंत्र है, और बस एक ही है, इसका कार्य प्रायोगिक खरगोशों के रूप में कक्षाओं के साथ काम करना है। चाहे आपको विधि के काम करने के समय के बारे में जानकारी प्राप्त करने की आवश्यकता हो या बस आपके द्वारा लोड की गई कक्षा का नाम पता करें - यह तंत्र बचाव में आएगा;
एक पूरे के रूप में जावा एक खुला और रचनात्मक मंच है। इसमें ओपन सोर्स एप्लिकेशन (किसी अन्य भाषा में) न केवल उनकी कार्यक्षमता के लिए उपयोगी हैं, बल्कि मूल्यवान विचार भी हैं जो उनके स्रोत कोड पर अध्ययन करके चमकाया जा सकता है। और स्रोत कोड की कमी अक्सर जावा अनुप्रयोगों के लिए कोई समस्या नहीं है। लगभग किसी भी संकलित जावा वर्ग के स्रोत कोड को प्रदर्शित करने के लिए कई उपकरण उपलब्ध हैं। उनकी मदद से, आप आसानी से लगभग किसी भी वर्ग और विधि के कोड का विश्लेषण कर सकते हैं, यहां तक कि रूपरेखा के मूल से (उदाहरण के लिए, rt.jar फ़ाइल से), ज़ाहिर है, मूल तरीकों के अपवाद के साथ। इस और कई अन्य परियोजनाओं पर काम करने में, लेखक मुक्त जावा डेकोम्पाइलर उपयोगिता के साथ काम में आया, जो आपको लगभग किसी भी संकलित जावा वर्ग के स्रोत कोड को देखने की अनुमति देता है। विशेष रूप से mesmerizing जावा कर्नेल स्रोत कोड के उस हिस्से को देखने का अवसर है जो स्वयं जावा में लिखा गया है, यदि, उदाहरण के लिए, आप rt.jar फ़ाइल को JRE फ़ोल्डर में खोलते हैं।

उपयोग किए गए स्रोतों की सूची

जावा में कक्षा लोडर के बारे में लेख:

अन्य उपयोगी लिंक:

stackoverflow.com/questions/3933300/difference-between-java-opts-and-java-tool-options - JAVA_OPTS और JAVA_TOOL_OPT वैरिएबल के बारे में प्रश्न;
docs.oracle.com/javase/1.4.2/docs/api/java/lang/ClassLoader.html#getSystemClassLoader - सिस्टम बूटलोडर को कैसे ओवरराइड करना है;
www.sql.ru/forum/actualthread.aspx?tid=858652 - इस विषय ने क्लास लोडर के बजाय इंस्ट्रूमेंटेशन का उपयोग करने के विचार को प्रेरित किया;
www.exampledepot.com/egs/java.lang/PropCmdLine.html - कमांड लाइन से जावा सिस्टम प्रॉपर्टी का मान कैसे सेट करें;
docs.oracle.com/javase/1.4.2/docs/guide/extensions/spec.html - कैसे lib / ext फ़ोल्डर में पथ प्राप्त करना है;
www.javalobby.org/java/forums/t19309.html - लेख एक सरल ट्रांसफार्मर वर्ग का एक उदाहरण प्रदान करता है;
Today.java.net/pub/a/today/2008/04/24/add-logging-at-class-load-time-with-instrumentation.html - लेख सभी भरी हुई कक्षाओं में मजबूर लॉगिंग की एक समान समस्या हल करता है;
java.decompiler.free.fr Java Decompiler प्रोजेक्ट का मुख पृष्ठ है।
www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html - हॉटस्पॉट JVM के लिए कुछ स्टार्टअप मापदंडों का वर्णन
q-redux.blogspot.com/2011/01/inspecting-hotspot-jvm-options.html - शायद ही कभी इस्तेमाल किए गए हॉटस्पॉट JVM लॉन्च विकल्पों के बारे में एक और लेख
habrahabr.ru/post/140133 - कुछ एप्लिकेशन सर्वर में क्लास लोडर की सुविधाओं के बारे में लेख