संकलक/जेवीएम सिर्फ "बस काम" ऑटोबॉक्सिंग क्यों नहीं कर सकता?

Question

Autoboxing बल्कि डरावना है। जब मैं पूरी तरह से == और .equals के बीच अंतर समझना मैं लेकिन मदद नहीं कर सकता मुझे से बाहर का पालन बग नरक है:

final List<Integer> foo = Arrays.asList(1, 1000); 
    final List<Integer> bar = Arrays.asList(1, 1000); 
    System.out.println(foo.get(0) == bar.get(0)); 
    System.out.println(foo.get(1) == bar.get(1)); 

प्रिंट कि

true 
false 

वे इसे इस तरह क्यों किया? यह कैश इंटीग्रर्स के साथ कुछ करने के लिए है, लेकिन अगर ऐसा है तो वे प्रोग्राम द्वारा उपयोग किए जाने वाले सभी इंटीग्रियों को कैश क्यों नहीं करते? या JVM हमेशा प्राचीन के लिए ऑटो अनबॉक्स क्यों नहीं करता है?

प्रिंटिंग झूठी झूठी या सच्ची सत्य बेहतर तरीके से होती।

संपादित

मैं पुराने कोड का टूटना सहमत नहीं हैं। foo.get(0) == bar.get(0) होने से सच हो गया है कि आप कोड को तोड़ चुके हैं।

इस बाइट कोड में पूर्णांक के साथ पूर्णांक की जगह (जब तक यह शून्य सौंपा कभी नहीं किया गया है)

Answer 1

• वे इसे इस तरह क्यों किया है?

-128 और 127 के बीच प्रत्येक इंटीजर जावा द्वारा कैश किया जाता है। उन्होंने प्रदर्शन लाभ के लिए, माना जाता है। भले ही वे इस फैसले पर वापस जाना चाहते थे, फिर भी यह संभावना नहीं है कि वे करेंगे। अगर किसी ने इस पर निर्भर कोड बनाया है, तो इसे हटाए जाने पर उनका कोड टूट जाएगा। शौक कोडिंग के लिए, इससे कोई फर्क नहीं पड़ता, लेकिन एंटरप्राइज़ कोड के लिए, लोग परेशान हो जाते हैं और मुकदमे होते हैं।

• वे प्रोग्राम द्वारा उपयोग किए जाने वाले सभी इंटीग्रियों को कैश क्यों नहीं करते हैं?

सभी इंटीग्रियों को कैश नहीं किया जा सकता है, क्योंकि स्मृति प्रभाव बहुत बड़ा होगा।

• क्यों JVM हमेशा प्राचीन के लिए ऑटो अनबॉक्स नहीं करता है?

क्योंकि JVM नहीं जानता कि आप क्या चाहते थे। साथ ही, यह परिवर्तन आसानी से विरासत कोड को तोड़ सकता है जो इस मामले को संभालने के लिए नहीं बनाया गया है।

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

बल्कि तो इस बारे में बहुत कठिन चिंता, बस के बजाय इस नियम याद रखें: जब तक आप उनके संदर्भ से उनकी तुलना की जा करने का इरादा

कभी == के साथ वस्तुओं की तुलना करें। यदि आप ऐसा करते हैं, तो मैं उस परिदृश्य के बारे में नहीं सोच सकता जिसमें आप किसी समस्या में भाग लेंगे।

Answer 2

आप कल्पना कर सकते कितना बुरा प्रदर्शन करता है, तो हर Integer के लिए भूमि के ऊपर किए गए होगा द्वारा संकलक स्तर पर हल किया जा नहीं कर सकता नजरबंदी? new Integer के लिए भी काम नहीं करता है।

जावा भाषा (कोई JVM समस्या नहीं) हमेशा ऑटोबॉक्स नहीं हो सकती क्योंकि प्री-1.5 जावा के लिए डिज़ाइन किया गया कोड अभी भी काम करना चाहिए।

Answer 3

Integer बाइट रेंज में एक ही वस्तु है, क्योंकि वे कैश किए गए हैं। बाइट रेंज के बाहर Integer एस नहीं हैं। यदि सभी पूर्णांक कैश किए जाने थे, तो आवश्यक स्मृति की कल्पना करें।

और here

यह सब जादू का परिणाम से है कि आप काफी हद तक कुछ कैविएट्स के साथ, पूर्णांक और पूर्णांक के बीच के अंतर को अनदेखा कर सकते है। एक इंटीजर अभिव्यक्ति का शून्य मान हो सकता है। यदि आपका प्रोग्राम नलऑनबॉक्स को चालू करने का प्रयास करता है, तो यह एक NullPointerException फेंक देगा। == ऑपरेटर इंटीग्रेट एक्सप्रेशन पर इंटेगर एक्सप्रेशन और वैल्यू इक्विटी तुलना पर संदर्भ पहचान तुलना करता है। अंत में, प्रदर्शन मुक्केबाजी और unboxing के साथ जुड़े लागत, भले ही यह स्वचालित रूप से किया जाता है

Answer 4

यदि आप पूरी तरह से ऑटोबॉक्सिंग छोड़ते हैं, तो भी आपको यह व्यवहार मिलता है।

final List<Integer> foo = 
    Arrays.asList(new Integer(1), new Integer(1000)); 
final List<Integer> bar = 
    Arrays.asList(new Integer(1), new Integer(1000)); 

System.out.println(foo.get(0) == bar.get(0)); // false 
System.out.println(foo.get(1) == bar.get(1)); // false 

यही कारण है कि ग्रहण डिफ़ॉल्ट रूप से एक चेतावनी के रूप autoboxing गया है, एक कारण है: यदि आप किसी विशिष्ट व्यवहार चाहते

final List<Integer> foo = 
    Arrays.asList(Integer.valueOf(1), Integer.valueOf(1000)); 
final List<Integer> bar = 
    Arrays.asList(Integer.valueOf(1), Integer.valueOf(1000)); 

System.out.println(foo.get(0) == bar.get(0)); // true 
System.out.println(foo.get(1) == bar.get(1)); // false 

अधिक स्पष्ट रूप से दिखाएं।

Answer 5

बहुत से लोगों को इस समस्या के साथ समस्याएं हैं, यहां तक ​​कि लोग जावा के बारे में किताबें लिखते हैं।

Pro Java Programming में, नीचे केवल इंच नीचे लेखक एक पहचान हैशैप में एक कुंजी के रूप में ऑटो-बॉक्स किए गए इंटीग्रियों का उपयोग करने के मुद्दों के बारे में बात करते थे, वह एक WeakHashMap में ऑटो-बॉक्स वाली इंटीजर कुंजी का उपयोग करता है। उनके द्वारा उपयोग किए जाने वाले उदाहरण मान 128 से अधिक हैं, इसलिए उनकी कचरा संग्रह कॉल सफल होती है। यदि कोई व्यक्ति अपने उदाहरण का उपयोग करना चाहता था और 128 से छोटे मानों का उपयोग करता था, तो उसका उदाहरण असफल हो जाएगा (कुंजी को परमा-कैश किया जा रहा है)।

Answer 6

जब आप लिखना

foo.get(0) 

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

System.out.println(foo.get(0).intValue() == bar.get(0).intValue()); 

नहीं

System.out.println(foo.get(0) == bar.get(0)); 

लिखने के लिए क्योंकि है कि एक पूरी तरह से अलग मतलब है।