ऑब्जेक्ट को var से बदलें: क्या गलत हो सकता है?

मैं हाल ही में एक स्थिति में आया था जो जावा 10 प्रोग्राम में वर्जन के साथ ऑब्जेक्ट की जगह रनटाइम पर एक अपवाद फेंकता है। मुझे इस प्रभाव को प्राप्त करने के कितने अलग-अलग तरीकों में दिलचस्पी थी, और मैंने इस मुद्दे को समुदाय को संबोधित किया:

यह पता चला कि आप विभिन्न तरीकों से प्रभाव को प्राप्त कर सकते हैं। यद्यपि वे सभी थोड़े जटिल हैं, लेकिन इस तरह के कार्य के उदाहरण के साथ भाषा की विभिन्न सूक्ष्मताओं को याद करना दिलचस्प है। आइए देखें कि क्या तरीके पाए गए।

प्रतिभागियों

जवाब देने वालों में कई प्रसिद्ध और बहुत लोग नहीं थे। यह सर्गेई बाइसेप्ड ईगोरोव , पिवस्टल कर्मचारी, स्पीकर, टेस्टकेंटर के रचनाकारों में से एक है। यह विक्टर पोलिशचुक है , जो खूनी उद्यम के बारे में रिपोर्ट के लिए प्रसिद्ध है। Google से निकिता आर्युतुशोव को भी नोट किया; दिमित्री मिखाइलोव और मैकसीमो । लेकिन मुझे Wouter Coekaerts के आगमन से विशेष रूप से खुशी हुई। वह पिछले साल अपने लेख के लिए जाने जाते हैं, जहां वह जावा प्रकार प्रणाली से गुजरे थे और बताया था कि यह कैसे टूट जाता है। इस लेख में से कुछ जार्च और मैंने जावा पज़लर्स की चौथी रिलीज़ में भी इस्तेमाल किया।

कार्य और समाधान

तो, हमारे कार्य का सार यह है: एक जावा प्रोग्राम है जिसमें फॉर्म Object x = ... (ईमानदार मानक java.lang.Object , कोई प्रकार प्रतिस्थापन) के एक चर की घोषणा है। कार्यक्रम "ओके" की तरह कुछ को संकलित करता है, चलाता है, और प्रिंट करता है। हम Object को var साथ प्रतिस्थापित करते हैं, जिसके लिए स्वचालित प्रकार की आवश्यकता होती है, जिसके बाद प्रोग्राम को संकलित करना जारी रहता है, लेकिन अपवाद के साथ लॉन्च पर क्रैश हो जाता है।

समाधानों को मोटे तौर पर दो समूहों में विभाजित किया जा सकता है। पहले में, var की जगह लेने के बाद, वैरिएबल आदिम हो जाता है (अर्थात, यह मूल रूप से ऑटोबॉक्सिंग था)। दूसरा प्रकार ऑब्जेक्ट रहता है, लेकिन Object तुलना में अधिक विशिष्ट है। यहां आप एक दिलचस्प उपसमूह को उजागर कर सकते हैं जो जेनरिक का उपयोग करता है।

मुक्केबाज़ी

किसी आदिम से किसी वस्तु को कैसे अलग किया जाए? कई अलग-अलग तरीके हैं। सबसे आसान पहचान के लिए जाँच करना है। यह समाधान निकिता द्वारा प्रस्तावित किया गया था:

 Object x = 1000; if (x == new Integer(1000)) throw new Error(); System.out.println("Ok"); 

जब x एक ऑब्जेक्ट होता है, तो यह निश्चित रूप से नए ऑब्जेक्ट new Integer(1000) संदर्भ में समान नहीं हो सकता है। और यदि यह एक आदिम है, तो भाषा के नियमों के अनुसार new Integer(1000) तुरंत एक आदिम में भी प्रकट होता है, और संख्याओं की तुलना आदिम के रूप में की जाती है।

एक और तरीका है ओवरलोड तरीके। आप अपना खुद का लिख ​​सकते हैं, लेकिन सर्गेई एक अधिक सुरुचिपूर्ण विकल्प के साथ आया: मानक पुस्तकालय का उपयोग करें। List.remove विधि List.remove , जो अतिभारित है और इंडेक्स द्वारा या तो एक तत्व को हटा सकता है यदि एक आदिम पारित किया जाता है, या किसी तत्व को मूल्य द्वारा पारित किया जाता है। यदि आप List<Integer> उपयोग करते हैं तो इससे बार-बार वास्तविक कार्यक्रमों में बग पैदा होते हैं। हमारे कार्य के लिए, समाधान इस तरह दिख सकता है:

 Object x = 1000; List<?> list = new ArrayList<>(); list.remove(x); System.out.println("Ok"); 

अब हम खाली सूची में से किसी न किसी तत्व 1000 को हटाने की कोशिश कर रहे हैं, यह सिर्फ एक बेकार कार्रवाई है। लेकिन अगर हम Object को var प्रतिस्थापित करते हैं, तो हम इंडेक्स 1000 के साथ एलिमेंट को IndexOutOfBoundsException एक अन्य विधि को कॉल करेंगे। और यह पहले से ही IndexOutOfBoundsException ओर जाता है।

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

 Object x = 40; try { throw new Error("Oops :" + (char)x); } catch (ClassCastException e) { System.out.println("Ok"); } 

यहाँ, ClassCastException अपेक्षित व्यवहार है, फिर प्रोग्राम सामान्य रूप से बाहर निकलता है। लेकिन var का उपयोग करने के बाद var यह अपवाद गायब हो जाता है, और हम कुछ और फेंक देते हैं। मुझे आश्चर्य है कि अगर यह खूनी उद्यम से वास्तविक कोड से प्रेरित है?

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

 Object x = 1.0; System.out.println(String.valueOf(false ? x : 100000000000L).substring(12) + "Ok"); 

इस विधि के बीच अंतर यह है कि हम सीधे x के मान का उपयोग नहीं करते हैं, लेकिन टाइप x अभिव्यक्ति के प्रकार को false ? x : 100000000000L से प्रभावित करता है false ? x : 100000000000L false ? x : 100000000000L । यदि x एक Object , तो संपूर्ण अभिव्यक्ति का प्रकार Object , और फिर हमारे पास सिर्फ बॉक्सिंग है, String.valueOf() 100000000000 स्ट्रिंग String.valueOf() , String.valueOf() substring(12) एक खाली स्ट्रिंग है। यदि आप var उपयोग करते हैं, तो टाइप x double हो जाता है, और इसलिए प्रकार false ? x : 100000000000L false ? x : 100000000000L भी double , यानी 100000000000L 1.0E11 में बदल जाएगा, जहां यह 12 अक्षरों से बहुत कम है, इसलिए कॉलिंग substring StringIndexOutOfBoundsException ओर जाता है।

अंत में, हम इस तथ्य का लाभ उठाते हैं कि एक चर वास्तव में निर्माण के बाद बदला जा सकता है। और ऑब्जेक्ट चर में, आदिम के विपरीत, आप null डाल सकते हैं। एक चर में null करना आसान है, कई तरीके हैं। लेकिन यहाँ, राउटर ने भी हास्यास्पद Integer.getInteger विधि का उपयोग करके एक रचनात्मक तरीका अपनाया:

 Object x = 1; x = Integer.getInteger("moo"); System.out.println("Ok"); 

हर कोई नहीं जानता है कि यह विधि एक सिस्टम गुण पढ़ती है जिसे moo कहा जाता है और, अगर कोई एक है, तो इसे एक संख्या में बदलने की कोशिश करता है, अन्यथा यह null । यदि कोई संपत्ति नहीं है, तो हम चुपचाप ऑब्जेक्ट को null असाइन करते हैं, लेकिन जब यह एक आदिम (स्वचालित बॉक्सिंग होता है) को असाइन करने का प्रयास करते समय NullPointerException से गिर जाता है। यह आसान जरूर हो सकता था। किसी न किसी संस्करण x = null; यह क्रॉल नहीं करता - यह संकलन नहीं करता है, लेकिन कंपाइलर इसे अब निगल जाएगा:

 Object x = 1; x = (Integer)null; System.out.println("Ok"); 

वस्तु प्रकार

मान लीजिए कि आप अब आदिम के साथ नहीं खेल सकते हैं। आप और क्या सोच सकते हैं?

खैर, सबसे पहले, दिमित्री द्वारा प्रस्तावित सबसे सरल विधि अधिभार विधि:

 public static void main(String[] args) { Object x = "Ok"; sayWhat(x); } static void sayWhat(Object x) { System.out.println(x); } static void sayWhat(String x) { throw new Error(); } 

जावा में अतिभारित तरीकों को जोड़ना संकलित अवस्था में, सांख्यिकीय रूप से होता है। SayWhat sayWhat(Object) विधि को sayWhat(Object) , लेकिन यदि हम टाइप x स्वचालित रूप से अनुमान लगाते हैं, तो String sayWhat(String) , और इसलिए अधिक विशिष्ट sayWhat(String) विधि लिंक की जाएगी।

जावा में अस्पष्ट कॉल करने का एक अन्य तरीका चर तर्कों (वेरगेज) का उपयोग करना है। राउटर ने इसे फिर से याद किया:

 Object x = new Object[] {}; Arrays.asList(x).get(0); System.out.println("Ok"); 

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

Maccimo कट्टर के लिए चला गया: उन्होंने मेथडल एपीआई के माध्यम से प्रिंटल कॉल करने का फैसला किया:

 Object x = "Ok"; MethodHandles.Lookup lookup = MethodHandles.lookup(); MethodHandle mh = lookup.findVirtual( PrintStream.class, "println", MethodType.methodType(void.class, Object.class)); mh.invokeExact(System.out, x); 

invokeExact विधि और java.lang.invoke कई अन्य तरीकों में तथाकथित "पॉलीमॉर्फिक हस्ताक्षर" हैं। यद्यपि इसे सामान्य वैरिएग invokeExact(Object... args) विधि के रूप में घोषित किया गया है, यह मानक सरणी पैकिंग में नहीं होता है। इसके बजाय, एक हस्ताक्षर बायटेकोड में उत्पन्न होता है जो वास्तव में पारित तर्कों के प्रकारों से मेल खाता है। invokeExact विधि invokeExact सुपर-फास्ट invokeExact मेथड invokeExact लिए डिज़ाइन किया गया है, इसलिए यह कास्टिंग या बॉक्सिंग जैसे कोई भी मानक तर्क रूपांतरण नहीं करता है। हैंडल मेथड टाइप से कॉल सिग्नेचर के मिलान की उम्मीद की जाती है। इसे रनटाइम पर चेक किया जाता है, और जैसा कि var मामले में टूटा है, हमें एक WrongMethodTypeException ।

जेनरिक

बेशक, जावा में किसी भी कार्य के लिए प्रकारों का मानकीकरण एक ट्विंकल जोड़ सकता है। दिमित्री ने कोड के समान एक समाधान लाया जिसे मैं शुरू में भर आया था। दिमित्री का निर्णय क्रिया है, इसलिए मैं अपना दिखाऊंगा:

 public static void main(String[] args) { Object x = foo(new StringBuilder()); System.out.println(x); } static <T> T foo(T x) { return (T)"Ok"; } 

StringBuilder रूप में टाइप T आउटपुट है, लेकिन इस कोड में StringBuilder में डायल-पीयर पर टाइप चेक डालने के लिए कंपाइलर की आवश्यकता नहीं है। यह उसके लिए पर्याप्त है कि StringBuilder को Object को सौंपा जा सकता है, जिसका अर्थ है कि सब कुछ ठीक है। कोई भी इस तथ्य के खिलाफ नहीं है कि रिटर्न वैल्यू के साथ विधि StringBuilder वास्तव में स्ट्रिंग लौटाता है यदि आपने परिणाम प्रकार के एक चर को परिणाम सौंपा है। संकलक ईमानदारी से चेतावनी देता है कि आपके पास एक अनियंत्रित डाली है, जिसका अर्थ है कि वह अपने हाथों को धोता है। हालाँकि, जब x को var साथ प्रतिस्थापित किया जाता है var टाइप x को StringBuilder रूप में भी प्रदर्शित किया जाता है, और यह अब बिना जाँच के संभव नहीं है, क्योंकि StringBuilder प्रकार चर के लिए कुछ और असाइन करना बेकार है। परिणामस्वरूप, var बदलने के बाद var प्रोग्राम सुरक्षित रूप से ClassCastException साथ क्रैश हो जाता है।

राउटर ने मानक तरीकों का उपयोग करके इस समाधान का एक प्रकार सुझाया:

 Object o = ((List<String>)(List)List.of(1)).get(0); System.out.println("Ok"); 

अंत में, Wouter का एक अन्य विकल्प:

 Object x = ""; TreeSet<?> set = Stream.of(x) .collect(toCollection(() -> new TreeSet<>((a, b) -> 0))); if (set.contains(1)) { System.out.println("Ok"); } 

यहां, var या Object के उपयोग के आधार पर स्ट्रीम टाइप को Stream<Object> या Stream<String> रूप में प्रदर्शित किया जाता है। तदनुसार, TreeSet प्रकार और तुलनित्र लंबोदर प्रकार प्रदर्शित किए जाते हैं। var के मामले में, स्ट्रिंग्स को लैम्ब्डा में आना चाहिए, इसलिए लैम्बडा रनटाइम प्रतिनिधित्व जेनरेट करते समय, एक प्रकार का रूपांतरण स्वचालित रूप से डाला जाता है, जो एक ClassCastException को एक यूनिट डालने की कोशिश करते समय ClassCastException देता है।

सामान्य तौर पर, परिणाम बहुत उबाऊ था। यदि आप var को तोड़ने के लिए मूलभूत रूप से भिन्न तरीकों के साथ आ सकते हैं, तो टिप्पणियों में लिखें।