शायद आप में से कई लोग सवाल पूछ रहे हैं जैसे, "यदि कोई व्यक्ति मेरे आवेदन में पुस्तकालय का गलत संस्करण डालता है तो क्या होगा?" प्रश्न अच्छा है, लेकिन आपको इस विषय में इसका उत्तर और कुछ अन्य मिलेंगे। बीज कार्य के लिए: दो इंटरफेस और एक वर्ग है कि उनमें से एक को लागू करते हैं:

public interface A { //... } public interface B { //... } public class C implements A { //... } 

और यह भी एक वर्ग है कि एक foo विधि A और B लिए अतिभारित है B इस विधि को कक्षा C उदाहरण से कहा जाता C :

 public class CompatibilityChecker { public String foo(A a) { return "A"; } public String foo(B b) { return "B"; } public static void main(String[] args) { CompatibilityChecker checker = new CompatibilityChecker(); System.out.println(checker.foo(new C())); } } 

यह स्पष्ट है कि "ए" प्रदर्शित किया जाएगा। यह भी उतना ही स्पष्ट है कि यदि आप कहते हैं कि C implements A, B करता C implements A, B , तो आपको एक संकलन त्रुटि मिलती है ( उन लोगों के लिए जो उत्तरार्द्ध के बारे में स्पष्ट नहीं हैं, मैं इस बारे में पढ़ने की सिफारिश कर सकता हूं कि तरीकों का चयन कैसे किया जाता है। उदाहरण के लिए, मानक में खंड 15.12.2 या अधिक में। बस स्थानों का वर्णन )।
लेकिन तब क्या होता है जब हम केवल C.java को फिर से C.java और फिर मौजूदा क्लास फाइल से CompatibilityChecker चलाते हैं, यह एक अधिक जटिल समस्या है। में रुचि रखते हैं? मैं कटौती के लिए पूछना!

स्थैतिक प्रेषण

जो लोग जानते हैं कि संकलन के दौरान अधिभार वाले तरीकों का चयन किया जाता है, वे महसूस कर सकते हैं कि इस कारण से क्लास फ़ाइल में तुरंत जानकारी होगी कि किस पद्धति से कॉल करना है, और इसलिए "ए" आउटपुट होगा। इस धारणा की जाँच करें:

 public static void main(java.lang.String[]); Code: 0: new #4; //class CompatibilityChecker 3: dup 4: invokespecial #5; //Method "<init>":()V 7: astore_1 8: getstatic #6; //Field java/lang/System.out:Ljava/io/PrintStream; 11: aload_1 12: new #7; //class C 15: dup 16: invokespecial #8; //Method C."<init>":()V 19: invokevirtual #9; //Method foo:(LA;)Ljava/lang/String; 22: invokevirtual #10; //Method java/io/PrintStream.println:(Ljava/lang/String;)V 25: return 

दरअसल, जैसा कि आप इंडेंटेड इंस्ट्रक्शन 19 से देख सकते हैं, एक बहुत ही विशिष्ट तरीका कहा जा रहा है। हालाँकि, जिन लोगों ने सत्यापनकर्ता के बारे में सुना है, वे आपत्ति कर सकते हैं और मान सकते हैं कि वह उस पर ध्यान देंगे ये कुछ गलत मधुमक्खियाँ हैं क्लास C बदल गया है और एक अपवाद फेंक देगा। सौभाग्य से, वे गलत हैं, क्योंकि सत्यापनकर्ता केवल कक्षाओं और इंटरफेस की संरचना की शुद्धता की जांच करता है, न कि वर्ग फ़ाइलों के संस्करणों के पत्राचार।

इसलिए, अपना कोड चलाएं और सुनिश्चित करें कि प्रारंभिक धारणा सही थी: वास्तव में "ए" प्रदर्शित किया जाएगा।

इसके अलावा, हम मान सकते हैं कि वर्चुअल एड्रेस टेबल में कुछ गलत एड्रेस हो सकता है, और इसलिए सब कुछ NoSuchMethodError में NoSuchMethodError साथ टूट जाएगा। यह धारणा भी त्रुटिपूर्ण है, क्योंकि foo(A) विधि को कहा जाता है, और आभासी तालिका में यह एकमात्र है। एक और बात यह है कि अगर वारिस इसे फिर से परिभाषित कर रहे थे ...

गतिशील प्रेषण

मान लें कि हमारे पास निम्नलिखित तीन कक्षाएं हैं:

 public class A { public String foo() { return "A"; } } public class B extends A { @Override public String foo() { return "B"; } } public class C extends A { @Override public String foo() { return super.foo() + "C"; } } 

और वर्ग जो foo को अलग-अलग तरीकों से कहता है:

 public class CompatibilityChecker { public static void main(String[] args) { A a = new A(); A ab = new B(); B bb = new B(); A ac = new C(); C cc = new C(); System.out.println(a.foo()); System.out.println(ab.foo()); System.out.println(bb.foo()); System.out.println(ac.foo()); System.out.println(cc.foo()); } } 

हर कोई, निश्चित रूप से जानता है कि चूंकि रनटाइम में पुन: असाइन किए गए प्रकार चुनिंदा तरीके हैं, इसलिए प्रारंभिक आउटपुट इस तरह होगा:

 A B B AC AC 

निम्नलिखित कोड को संकलित करने के परिणामस्वरूप A से फ़ाइल वर्ग को बदलकर यह चाल करने का समय है:

 public class A { public String foo(Object dummy) { return "A"; } } 

यह समझने के लिए कि इस मामले में क्या होगा, काफी सरल है। सबसे पहले, सभी तरीकों को कॉल करने का प्रयास करते हैं जहां foo को कक्षा A एक उदाहरण पर बुलाया जाता है, निश्चित रूप से NoSuchMethodError साथ बाहर उड़ जाएगा। इन प्रयासों के बीच वर्ग C में super.foo() को कॉल भी है C दूसरे, जैसा कि हमने पहले देखा, B.foo() विधि को सफलतापूर्वक कहा जाता है।

अब चलो रणनीति को बदलते हैं: फिर से, जिस तरह से यह था, वैसे ही A.foo । लेकिन अब B और C को बदल दें, पूरी तरह से foo विधि के पुनर्परिवर्तन को हटा दें:

 public class B extends A {} public class C extends A {} 

जब कोड चलाया जाता है, तो डायनेमिक प्रेषण A.foo लिए केवल एक प्रविष्टि का पता A.foo , और इसलिए सभी मामलों में यह इसे कॉल करेगा, जिसके परिणामस्वरूप हम कंसोल में केवल "ए" अक्षर और किसी भी अपवाद की पूर्ण अनुपस्थिति देखेंगे।

हम फिर से B और C में तरीकों को फिर से परिभाषित करके अपना शोध जारी रखते हैं। शुरू करने के बाद, जैसा कि हम उम्मीद कर सकते हैं, गतिशील प्रेषण वर्चुअल टेबल में सभी रिकॉर्डों का पता लगाएगा और ठीक उसी तरह का आउटपुट देगा जैसा कि हम सब कुछ फिर से प्राप्त करके प्राप्त करेंगे।

अनुचित प्रकार के क्षेत्र

पहले हमने केवल तरीकों के साथ प्रयोग करने की कोशिश की। अब देखते हैं कि खेतों का क्या होता है। मान लीजिए कि एक ऐसा वर्ग है जो एक अंतर मान रखता है और इस वर्ग का उत्तराधिकारी है:

 public class A { int answer; } public class B extends A {} 

और, परंपरागत रूप से, एक वर्ग B उपभोक्ता:

 public class CompatibilityChecker { public static void main(String[] args) { B b = new B(); b.answer = 42; } } 

अब उसी नाम के साथ वर्ग B हमारे अपने क्षेत्र में जोड़ें:

 public class B extends A { String answer; } 

आइए देखें कि CompatibilityChecker लिए कौन सा बायटेकोड जनरेट किया गया था:

 public static void main(java.lang.String[]); Code: 0: new #2; //class B 3: dup 4: invokespecial #3; //Method B."<init>":()V 7: astore_1 8: aload_1 9: bipush 42 11: putfield #4; //Field B.answer:I 14: return 

यह लिस्टिंग भ्रामक हो सकती है, क्योंकि यह टिप्पणी में 11 का संकेत है कि ऐसा लगता है कि यह क्षेत्र बी का है। इसलिए, हमें यह मान लेना चाहिए कि जब हम B फिर से जोड़ेंगे B तो हम एक त्रुटि का सामना करेंगे। हालांकि, यह पता चला है कि ऐसा नहीं है। चूंकि केवल आधार वर्ग का भौतिक रूप से एक क्षेत्र होता है, putfield का ऑपरेंड ठीक उसी क्षेत्र को इंगित करता है जिसकी आपको आवश्यकता है, जिसके परिणामस्वरूप परिवर्तनों के बाद, कोड काम करना जारी रखता है।

और विनिर्देश क्या कहता है?

विनिर्देश में, एक पूरा अध्याय द्विआधारी संगतता के लिए आरक्षित है, जिसमें मूल अवधारणा "बाइनरी संगत" या "सुरक्षित" परिवर्तन है। विनिर्देश में कहा गया है कि जब केवल सुरक्षित परिवर्तन किए जाते हैं, तो एप्लिकेशन को बाकी सभी चीजों को फिर से लिंक किए बिना सुरक्षित रूप से चलाने और त्रुटियों को लिंक करने की गारंटी दी जाती है। अजीब तरह से पर्याप्त है, लेकिन पूरे विशाल अध्याय में द्विआधारी संगत संचालन की कोई सटीक परिभाषा नहीं है, हालांकि उदाहरणों का एक गुच्छा है:

• मौजूदा तरीकों, कंस्ट्रक्टर्स या इनिशियलाइज़ेशन ब्लॉक के कार्यान्वयन को बदलना
• मौजूदा क्षेत्रों और इंटरफेस के लिए नए क्षेत्रों, विधियों और कंस्ट्रक्टर्स को जोड़ना
• निजी क्षेत्रों, विधियों और वर्ग निर्माणकर्ताओं को हटाना
• कक्षा पदानुक्रम तक विधियों को स्थानांतरित करें
• नई कक्षाएं और इंटरफेस जोड़ना

शायद यह बाइनरी संगत संचालन की इतनी कमजोर परिभाषा के कारण है कि समस्याएं पैदा होती हैं।

मरहम में उड़ना

जैसा कि यह निकला, विनिर्देश पर्याप्त सख्त नहीं है, और आप एक ऐसे मामले के साथ आ सकते हैं जिसमें सुरक्षित परिवर्तन लिंक में त्रुटि का कारण बनेंगे। एक इंटरफ़ेस पर विचार करें, एक वर्ग जो इस इंटरफ़ेस को लागू करता है, और एक अन्य वर्ग जो उनका उपयोग करता है:

 public interface A {} public class B implements A {} public class CompatibilityChecker { public static void main(String[] args) { A b = new B(); } } 

हम दो सुरक्षित बदलाव करेंगे: इंटरफ़ेस A में foo विधि जोड़ें और CompatibilityChecker क्लास की main विधि के कार्यान्वयन में बदलाव करें:

 public interface A { void foo(); } public class CompatibilityChecker { public static void main(String[] args) { A b = new B(); b.foo(); } } 

स्टार्टअप पर, जैसा कि आप समझ सकते हैं, एक त्रुटि उत्पन्न होगी, जिसका नाम है AbstractMethodError: B.foo()V , जो सिद्धांत में नहीं होना चाहिए। यह समस्या जानी जाती है और जावा बाइटकोड प्रोसैसिंग के मूल में है। स्थिति को सुधारने के लिए प्रस्ताव थे, लेकिन अभी तक उन्होंने कुछ भी नहीं किया है।

अंत

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

लेख कुछ स्पष्ट बातों को संबोधित नहीं करता है। उदाहरण के लिए, कि तरीकों और वर्गों को हटाने या इंटरफ़ेस में क्लास बदलने जैसे असंगत बदलावों के साथ, NoSuchMethodError , NoClassDefFoundError या NoSuchMethodError जैसी बेरहम त्रुटियों को NoClassDefFoundError जाएगा।

मुझे सवालों के जवाब देने और टिप्पणियों और परिवर्धन को पढ़ने में खुशी होगी। वैसे, हब्रहाब पर मेरे दूसरे जीवन में यह मेरा पहला विषय है। मैं यह भी नहीं जानता कि मैं किस बारे में बात कर रहा हूँ।