IntelliJ IDEA का उपयोग किए बिना जावा में NPE नर्क को हराएं

त्याग

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

दूसरे, संसाधन में पहले से ही IntelliJ IDEA को समर्पित एक उत्कृष्ट लेख tr1cks है , जो पहले से ही मजबूत धारणा को पुष्ट करता है कि IDEA बहुत अच्छा है, और एक्लिप्स गरीबों के लिए है (जो कि एक संकेत बन गया है)। संतुलन के लिए, मैं ग्रहण पर ध्यान केंद्रित करूंगा।

मैं FindBugs प्रोजेक्ट एनोटेशन ( JSR 305 एनोटेशन के रूप में भी जाना जाता है) का उपयोग किसी विशिष्ट विकास परिवेश के लिए उनके बंधन की कमी के कारण (प्रशंसकों org.eclipse.jdt.annotation.* और org.jetbrains.annotations.* ) का उपयोग कर सकते हैं org.eclipse.jdt.annotation.* इस तथ्य के कारण कि वे मावेन सेंट्रल में उपलब्ध हैं । मावेन का उपयोग करने वालों के लिए, बस निम्नलिखित को <dependencies/> अनुभाग में जोड़ें:

 <dependency> <groupId>com.google.code.findbugs</groupId> <artifactId>jsr305</artifactId> <version>3.0.0</version> </dependency> 

बस, मैं एक आरक्षण करता हूं

  @Nonnull public String getName() { // ... } 

और

  public @Nonnull String getName() { // ... } 

- ये दो बिल्कुल समतुल्य निर्माण हैं, हालांकि कुछ मामलों में प्राप्त बाईटेकोड के दो प्रकार बिल्कुल 1 बाइट से भिन्न हो सकते हैं (वैसे, आप क्यों सोचते हैं?)

ग्रहण

निम्नलिखित में से सभी को ग्रहण 4.4 (लूना) पर परीक्षण किया गया है। उसी समय, यदि मेरी मेमोरी मुझे सही काम करती है, तो वर्णित कार्यक्षमता पहले से ही 3.8 (और संभवतः पहले) में मौजूद थी।

समायोजन

• यदि आप M2Eclipse मॉड्यूल का उपयोग करते हैं, तो एनोटेशन को तुरंत जोड़ दिया जाता है:
  
  
  
  
  
• इसके बाद, आपको वैश्विक सेटिंग्स या प्रोजेक्ट सेटिंग्स में जाने की जरूरत है, जावा -> कंपाइलर -> त्रुटियां / चेतावनी -> अशक्त विश्लेषण का चयन करें और एनोटेशन-आधारित अशक्त विश्लेषण सक्षम करें ।
  
  
  
  
  
• उसके बाद, ग्रहण पूछेगा कि क्या नल सूचक पहुंच और संभावित नल सूचक पहुंच समस्याओं का स्तर "त्रुटि" तक उठाया गया है। यह ध्यान में रखा जाना चाहिए कि, सहमत होने से, आपको मौजूदा कोड के लिए कई संकलन त्रुटियां प्राप्त होंगी, इसलिए मैं आपको सलाह दूंगा कि आप इसे केवल नई परियोजनाओं के लिए करें, अन्यथा "चेतावनी" स्तर छोड़ दें।
• अब आप रिक्त विशिष्टियों के ध्वज के लिए डिफ़ॉल्ट एनोटेशन का उपयोग करें और फ़ैक्टरी के बजाय JSR 305 एनोटेशन का चयन करें:
  
  
  
  
  
• फ़ील्ड ध्वज के लिए सिंटैक्टिक नल विश्लेषण सक्षम करें चुना जाना चाहिए: इस मामले में झूठी सकारात्मक की संख्या (और वे होगी) घट जाएगी।
• पैकेज ध्वज पर मिसिंग '@NonNullByDefault' एनोटेशन भी चुनने योग्य है (इस ध्वज की उपस्थिति ग्रहण से IDEA की तुलना करती है), लेकिन @NonNullByDefault या @ParametersAreNonnullByDefault की मदद से केवल नए, बनाए गए पैकेज (भारी मात्रा में लिखा गया) ऑफल JDK, कॉर्नी "गैर-शून्य मापदंडों" की आवश्यकता को पूरा नहीं करता है और संकलन त्रुटियों को जन्म देगा)। बस मामले में, पूरे पैकेज पर टिप्पणी (फ़ाइल "पैकेज-info.java") में "लटका" जैसे हैं:
  
  

   @ParametersAreNonnullByDefault package com.example; import javax.annotation.ParametersAreNonnullByDefault; 

गलत सकारात्मक निदान

यदि निदान गलत है, तो कुछ लोग खुश होंगे। सौभाग्य से, यह कहने का अवसर है: "डॉक्टर, आप नशे में थे और किसी और के रक्त का विश्लेषण किया था!"

समस्या

चित्र से पता चलता है कि ग्रहण यह निर्धारित करने में सक्षम नहीं है कि (एकल-थ्रेडेड परिदृश्य में, निश्चित रूप से), फ़ील्ड field hashCode() कॉल के समय null नहीं हो सकती:


हां, निश्चित रूप से, हम @SuppressWarnings("null") साथ पूरी विधि को चिह्नित कर सकते हैं, लेकिन यह अशक्त विश्लेषण के सभी लाभों को शून्य कर देगा।

वर्कअराउंड ०

assert जोड़ें:

वर्कअराउंड 1

लंबा, लेकिन यह भी संभव है। फ़ील्ड मान को एक स्थानीय चर में @Nonnull , इसे @Nonnull रूप में चिह्नित करें और फिर हम इसके साथ काम करेंगे:

नुकसान

जावा 1.8 से शुरू होकर, मेटाडेटा का एक नया प्रकार समर्थित है - प्रकार एनोटेशन ( JSR 308 देखें) - और तदनुसार, एनोटेशन को स्पष्ट रूप से @Target निर्दिष्ट करने की आवश्यकता है। FindBugs एनोटेशन इस आवश्यकता को पूरा नहीं करते हैं। इसलिए, यदि आप 4.4 समावेशी (लूना) और जावा 1.8 तक ग्रहण का उपयोग करते हैं, तो फाइंडबग्स एनोटेशन का उपयोग करते हुए null विश्लेषण काम नहीं करेगा ( बग # 435805 )। सामान्य तौर पर, इस मामले में, ग्रहण 4.5 (मंगल) पर स्विच करना बेहतर होता है।

घर पढ़ने

• ग्रहण जेडीटी कोर में अशक्त विश्लेषण स्थिति
• ग्रहण केपलर और @ निबल

आईडिया

इंटेलीज आईडीईए, null विश्लेषण का समर्थन करता है, ऐसा लगता है, समय की शुरुआत से ( लगातार स्थितियों और अपवादों की जांच और @ नोटनल / @ निबल समस्याओं )।




क्या अच्छा है, पर्यावरण तुरंत "आउट ऑफ द बॉक्स" जेएसआर 305 सहित कई उपयुक्त एनोटेशन के बारे में जानता है:


केवल अफ़सोस की बात है कि, ग्रहण के विपरीत, पूरे पैकेज पर टिप्पणियां (जैसे @NonNullByDefault या @ParametersAreNonnullByDefault ) समर्थित नहीं हैं।

अद्यतन

असेंबली 138.1372 ( IDEA-125281 ), @ParametersAreNonnullByDefault और पैकेज स्तर पर @ParametersAreNullableByDefault से @ParametersAreNullableByDefault होने को मान्यता दी जाती है और उनका विश्लेषण किया जाता है, हालांकि वे सेटिंग्स ( Borz के लिए धन्यवाद) में कहीं भी प्रकट नहीं होते हैं। इसके अलावा, कार्यक्षमता IDEA 13.1.6 (135.1306 का निर्माण) में मौजूद है।

NetBeans

नेटबीन्स ने 7.3 के बाद से null विश्लेषण का समर्थन किया है, आगे देखें। ^{अंग्रेजी} लेख ।

टिप्पणी

यदि आप न केवल IDEs, बल्कि FindBugs का भी उपयोग करते हैं, तो संभावित रूप से वापसी करने वाले तरीकों को न केवल @Nullable रूप में चिह्नित किया जाना चाहिए, बल्कि @CheckForNull रूप में भी - FindBugs केवल तभी इसे "शांत" करेगा यदि यह @CheckForNull देखता है।

अच्छा बोनस nishtyaki साइड इफेक्ट

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

एक बार एक समय में ऐसे परीक्षण हुए जो गिरे नहीं, लेकिन बहुत चतुराई से नहीं लिखे गए थे। हां, आप गलत नहीं थे, यह जुनीत 3 है:

 public void test() throws Exception { final Calendar calendar = myVeryCleverNonStandardApiCall(); final int year = calendar.get(Calendar.YEAR); assertEquals(1997, year); assertEquals("1.1", System.getProperty("java.specification.version")); } 

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

 public void test() throws Exception { final Calendar calendar = myVeryCleverNonStandardApiCall(); final int year = calendar.get(Calendar.YEAR); // assertEquals(1997, year); // assertEquals("1.1", System.getProperty("java.specification.version")); } 

कुछ वर्षों के बाद, इसने संकलन करना भी बंद कर दिया, और अच्छे आँकड़ों की अभी भी आवश्यकता थी। परीक्षणों की फिर से मरम्मत की गई। चूंकि एनपीई से छुटकारा पाना असंभव था, और कोड का एक बड़ा हिस्सा फेंकने से ध्यान आकर्षित होगा, पुराना परीक्षण प्रच्छन्न था, और आंखों को टालने के लिए एक नया देरी के साथ एक नया पेश किया गया था:

 public void test() throws Exception { Thread.sleep(1000); } public void _test() throws Exception { final Calendar calendar = null; //myVeryCleverNonStandardApiCall(); final int year = calendar.get(Calendar.YEAR); // assertEquals(1997, year); // assertEquals("1.1", System.getProperty("java.specification.version")); } 

निष्कर्ष?

कभी-कभी यह समझ में आता है कि लेग कोड के लिए नल पॉइंटर एक्सेस और पोटेंशियल नल पॉइंटर एक्सेस के स्तर को भी "एरर" करने के लिए। विशेषकर विरासत कोड के लिए। आप कल्पना भी नहीं कर सकते हैं कि "बाइसन" क्या सक्षम है, जिसने बीस साल पहले आपके उत्पाद को शाब्दिक रूप से बनाया था और दस साल पहले सफलतापूर्वक कुछ Google या अमेज़ॅन के लिए छोड़ दिया था।

इच्छाओं

यदि C # का उपयोग करने वाले पाठकों में से लोग हैं, तो कृपया टिप्पणी करें - क्या Nullable जैसी अच्छी चीज़ की उपस्थिति के प्रकाश में C # के लिए प्रासंगिक समस्या है, और यदि ऐसा है, तो इसका क्या मतलब है?