JSR305 से javax.annotation का उपयोग करने का यह सही तरीका है?

Question

मैंने हाल ही में अपनी परियोजना में जेएसआर 305 के लिए आरआई जोड़ा है और इस तरह के मेरे इंटरफेस में एनोटेशन जोड़ रहा है:

public interface AccountService 
{ 
    @Nullable AccountResult consolidate(@Nonnull Date from, @Nonnull Date to) 
} 

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

Answer 1

मैं इसे क्यों आप एनोटेशन जोड़ रहे हैं पर निर्भर करता है लगता है।

तुम सिर्फ संदर्भ के लिए उन्हें जोड़ रहे हैं ताकि इंटरफेस के कार्यान्वयन जो आपके अपेक्षित डिजाइन पता है, तो ठीक है।

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

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

Answer 2

आप स्ट्रिंग का एक सख्त उपवर्ग के रूप में '@NonNull स्ट्रिंग' देख सकते हैं। अगर यह था सब के बाद, किसी भी गैर-शून्य स्ट्रिंग निश्चित रूप से एक 'instanceof' '@Nullable स्ट्रिंग है', लेकिन किसी भी instanceof '@Nullable स्ट्रिंग @NonNull स्ट्रिंग' 'का एक उदाहरण नहीं हो सकता है' (यह नहीं होगा शून्य, उदाहरण के लिए)।

इस तरह से देख रहे हैं, @Nullable और @NonNull प्रकार की जानकारी हैं, और इसलिए इंटरफेस में पूरी तरह से उचित हैं। आप कार्यान्वयनकर्ताओं को इंगित कर रहे हैं कि वे शून्य वापस आ सकते हैं, और उन्हें इनपुट नल के बारे में चिंता करने की ज़रूरत नहीं है, और आप कॉलर्स को इंगित कर रहे हैं कि उन्हें शून्य में नहीं जाना चाहिए, और उन्हें नल आउट होने की उम्मीद करनी चाहिए।

बेशक, यह सब बहुत उचित है, जबकि वेनिला जावैक v1.6 निश्चित रूप से इन नियमों में से किसी एक को लागू नहीं करता है जिस तरह से यह वास्तविक प्रकारों के लिए सुरक्षा प्रकार को लागू करता है। लेकिन कोई भी सपना देख सकता है, या कोई इन टिप्पणियों को सत्यापित करने का काम लेने के लिए पीएमडी या खोजबग जैसे कुछ का उपयोग कर सकता है।

@NonNull और @Nullable एनोटेशन पूरी पूर्णता टाइपिंग सिस्टम के लिए पर्याप्त नहीं हैं, हालांकि। मुझे वास्तव में पता नहीं है कि JSR305 इसका समाधान क्यों नहीं करता है, लेकिन तीसरा प्रकार है: "@MaybeNull"। यह जेनेरिक पैरामीटर के अंदर दिखाई देगा; कहीं और इसका अर्थ @Nullable जैसा ही होगा।

सार्वजनिक स्थैतिक शून्य addIfNotNull (सूची < @MaybeNull टी> सूची, @Nullable टी आइटम) { अगर (आइटम! = शून्य) list.add (आइटम); }

पहले 'टी' पर टिप्पणी नहीं है तो "@Nullable", तो आप, में गैर-शून्य सूचियों जो एक नहीं बल्कि बेकार एपीआई के लिए होगा पारित नहीं कर सका। दूसरी तरफ, यदि यह @ नॉननुल था, तो आप एक निरर्थक सूची नहीं पारित कर सकते थे। प्रैक्टिस में, इससे कोई फ़र्क नहीं पड़ता कि आप वहां क्या स्थानांतरित करते हैं, यह (ए) कभी भी NullPointerException का कारण नहीं बनता है, और (बी) कभी नहीं एनोटेशन का उल्लंघन करें। तो, आपको व्यक्त करने के लिए एक तरीका चाहिए: मुझे परवाह नहीं है कि यह विशेष 'टी' निरर्थक है या नहीं; जब मैं इसे पढ़ता हूं तो मैं शून्य-जांच करूँगा, और मैं कभी भी नल लिखूंगा, इसलिए इससे कोई फर्क नहीं पड़ता।

@MaybeNull और @Nullable के बीच अंतर के बीच 'अंतर के अनुरूप है? जेनेरिक में संख्या 'और' संख्या 'बढ़ाता है। जेनरिक के बाहर उनका मतलब एक ही बात है, लेकिन जेनेरिक में एक अंतर है।

तो, जल्द ही किसी भी कठोर टाइपकेक के लिए अपनी उम्मीदों को न रखें।

@Inherited केवल कक्षाओं के लिए काम करता है, लेकिन एक एनोटेट वापसी प्रकार और एनोटेट मापदंडों के लिए कुछ इसी तरह कल्पना कर सकते हैं।