2016-08-30 41 views
16

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

क्या कोई बाहरी एपीआई बदलने के बिना अस्पष्टता को हल करने का कोई तरीका सोच सकता है?

public class Vararg8 { 

    public Vararg8(final Object... os) {} 

    public Vararg8(final boolean b, 
        final String s, 
        final int... is) {} 

    public Vararg8() { 
     this(true, "test", 4, 5, 6); 
    } 
} 

उत्तर

18

आप एक स्पष्ट int[] सरणी पारित करके यह कर सकते हैं:

public Vararg8() 
{ 
    this(true, "test", new int[]{4, 5, 6}); 
} 

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

the appropriate JLS docs देखें:

पहले चरण (§15.12.2.2) मुक्केबाजी या unboxing रूपांतरण या वैरिएबल arity विधि मंगलाचरण के उपयोग की अनुमति के बिना अधिभार संकल्प प्रदर्शन करती है। यदि इस चरण के दौरान कोई लागू विधि नहीं मिलती है तो प्रसंस्करण दूसरे चरण तक जारी रहता है।

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

तीसरा चरण (§15.12.2.4) परिवर्तनीय धर्मार्थ विधियों, मुक्केबाजी और अनबॉक्सिंग के साथ ओवरलोडिंग को अनुमति देता है।

+0

स्पष्टीकरण और जेएलएस संदर्भ के लिए धन्यवाद।मुझे इस मल्टी-स्टेज रिज़ॉल्यूशन के बारे में पता नहीं था। – Ramses

3

इस प्रयास करें:

public Vararg8() 
{ 
    this(true, "test", new int[]{4, 5, 6}); 
} 
2

एक स्पष्ट पूर्णांक का उपयोग करें, आपकी समस्या का समाधान करना चाहिए।

public Vararg8() { 
     this(true, "test",new int[]{ 4, 5, 6}); 
    } 
0

चरित्र सरणी भी आपकी समस्या

public Vararg8() { 
      this(true, "test".toCharArray(), 4, 5, 6); 
     } 
+0

उदाहरण में प्रकार केवल एक उदाहरण थे, वास्तविक कोड ज्यादातर डोमेन विशिष्ट प्रकारों का उपयोग किया जाता था ... – Ramses

1

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

यदि आप पहले से ऑब्जेक्ट्स प्रकार का उपयोग कर रहे हैं, तो इस समाधान के लिए आपको कुछ भी खर्च नहीं होगा।

यह पसंद लगेगा यह:

public<A extends Boolean, B extends String, C extends Integer> Disambiguate(final A booleanPar, 
             final B stringPar, 
             final C... integerPar) {System.out.println("Im in the specific one");} 

public<T extends Object> Disambiguate(final T... os) {System.out.println("Im in the general one");} 

public static void main(String[] args) { 
    new Disambiguate(true, "test", 4, 5, 6); 
} 

आप 1.5 और उच्चतर के साथ "पश्चगामी संगतता के लिए" जेनरिक का उपयोग करें और ठीक काम कर रहा सभी मौजूदा कोड छोड़ने के लिए और एक नया एपीआई बना सकता है, कि में समस्या से बचने होगा भविष्य।