ऑब्जेक्ट्स.comपेयर() विधि का उद्देश्य क्या है?

Question

जावा 7 ने Objects कक्षा "null -safe या null -tolerant" विधियों को पेश किया, जिसमें compare(T, T, Comparator<T>) शामिल हैं। लेकिन जब मैं कभी बस बुला

comparator.compare(left, right); 

से अधिक

Objects.compare(left, right, comparator); 

का प्रयोग करेंगे?

Objects.compare केवल null -safe अगर comparator भी है, तो मैं तुलना-कॉल क्यों लपेटूं? ऑब्जेक्ट पहचान के लिए पहली जांच का अनुकूलन कुछ ऐसा लगता है जो तुलनित्र में ही किया जाना चाहिए। और व्यवहार में एकमात्र असली अंतर यह देख सकता है कि comparator.compare(left, right)NullPointerException फेंकता है यदि comparator, left और rightnull हैं, जबकि Objects.compare नहीं है; यह वास्तव में एक नई मानक पुस्तकालय विधि वारंट करने के लिए एक महत्वपूर्ण पर्याप्त विचार की तरह प्रतीत नहीं होता है।

क्या मुझे यहां कुछ स्पष्ट याद आ रही है?

Answer 1

यह खोदना दिलचस्प था। Objects कक्षा, .compare() विधि के साथ, जो डार्सी द्वारा 3b45b809d8ff में पेश की गई थी, और प्रतिबद्ध संदेश Bug 6797535 का हवाला देते हैं और इंगित करता है कि "शेरमेन" (जुआमिंग शेन?) इस पर हस्ताक्षर किए गए हैं। बग के अलावा सितंबर 200 9 से this thread पर चर्चा की गई है कि Objects में कौन सी विशेषताओं को जोड़ना है। धागे के लोगों में compare(int, int) (और पसंद) आदिम तुलनात्मक तरीकों को जोड़ने पर चर्चा करें, और आखिरकार इन्हें तय करें कि इन्हें अपने संबंधित रैपर वर्गों में रहना चाहिए (Integer.compare() देखें)। इस विधि को later in that thread पेश किया गया है लेकिन बिना किसी टिप्पणी के मुझे मिल सकता है।

बाद a patch is sent out for reviewObjects.compare() युक्त, और Joshua Bloch replies:

मुझे नहीं लगता कि आप इस विधि (तुलना (टी एक, टी बी, तुलनाकारी ग)) जोड़ना चाहिए है। इसकी उपयोगिता अस्पष्ट है, और इसमें इस वर्ग में अन्य विधियों के पावर-टू-वेट अनुपात नहीं है।

Darcy responds:

हाँ, मैं के साथ इस शामिल "आइटम 12: तुलनीय लागू करने पर विचार" मन में EJv2 से ।

यह मुझे स्पष्ट नहीं है कि यह विधि Item 12 के संबंध में तालिका में क्या लाती है, लेकिन यह मुद्दा फिर से नहीं उठाया गया प्रतीत होता है। मैं अनुमान लगाता हूं कि इरादा स्टाइलिस्ट कारणों के लिए आदिम compare() के बराबर विधि प्रदान करना था, लेकिन मुझे ऐसा सबूत नहीं मिला जो वास्तव में कारण था।

---

यह देख कि डार्सी और बलोच Objects.toString() विधि के बीच एक ही विनिमय इसी तरह बलोच ने आलोचना की है लायक है:

मैं करूंगा निश्चित रूप से/नहीं/इस विधि (Objects.toString) जोड़ें।यह उस टेबल पर कुछ भी नहीं लाता है जो पहले से मौजूद नहीं है। लोग जानते हैं और String.valueOf का उपयोग करें। चलो एक और विकल्प जोड़कर पानी को गंदे नहीं करते हैं।

लेकिन जैसा कि हम जानते हैं कि यह निकाला नहीं गया था, डार्सी बस जवाब दिया:

तो उल्लेख किया।

---

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

इस समान प्रश्न में रुचि हो सकती है (हालांकि इसके बारे में एक कार्यान्वयन विस्तार, नहीं एक API परिवर्तन है): Why is Arrays.fill() not used in HashMap.clear() anymore?