FindBugs जावा बेहतर सीखने में मदद करता है

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

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

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

टर्नरी ऑपरेटर ?:

ऐसा लगता है कि टर्नरी ऑपरेटर की तुलना में कुछ भी सरल नहीं है, लेकिन इसके नुकसान हैं। मैंने सोचा कि डिजाइनों में कोई बुनियादी अंतर नहीं था

Type var = condition ? valTrue : valFalse; 

और

 Type var; if(condition) var = valTrue; else var = valFalse; 

यह पता चला कि सूक्ष्मता है। चूंकि टर्नरी ऑपरेटर एक जटिल अभिव्यक्ति का हिस्सा हो सकता है, इसलिए इसका परिणाम एक विशिष्ट प्रकार का संकलन चरण में परिभाषित होना चाहिए। इसलिए, मानें कि यदि आइ-फॉर्म में सही स्थिति है, तो कंपाइलर टाइप टाइप करने के लिए तुरंत वैटल कर देता है, और एक टर्नरी ऑपरेटर के रूप में, यह पहले सामान्य प्रकार के वैलट्यू और वेलफ्लेस की ओर जाता है (इस तथ्य के बावजूद कि वेलफ्लेस का मूल्यांकन नहीं किया जाता है), और फिर परिणाम टाइप करने की ओर जाता है। टाइप करें। ज़बरदस्ती के नियम पूरी तरह से तुच्छ नहीं हैं यदि अभिव्यक्ति के ऊपर आदिम प्रकार (और डबल, आदि) के ऊपर आवरण मौजूद हैं। सभी नियम जेएलएस 15.25 में विस्तार से वर्णित हैं। आइए कुछ उदाहरण देखें।

 Number n = flag ? new Integer(1) : new Double(2.0); 

अगर झंडा लगाया गया तो n में क्या होगा? 1.0 के मान के साथ डबल ऑब्जेक्ट। ऑब्जेक्ट बनाने के लिए हमारे अनाड़ी प्रयास संकलक के लिए हास्यास्पद हैं। चूंकि दूसरे और तीसरे तर्क अलग-अलग आदिम प्रकारों पर आवरण होते हैं, इसलिए संकलक उन्हें विस्तारित करता है और अधिक सटीक प्रकार (इस मामले में, डबल) की ओर जाता है। और असाइनमेंट के लिए टर्नरी ऑपरेटर को निष्पादित करने के बाद, बॉक्सिंग फिर से किया जाता है। अनिवार्य रूप से, कोड इसके बराबर है:

 Number n; if( flag ) n = Double.valueOf((double) ( new Integer(1).intValue() )); else n = Double.valueOf(new Double(2.0).doubleValue()); 

संकलक के दृष्टिकोण से, कोड में कोई समस्या नहीं है और ठीक संकलन करता है। लेकिन FindBugs एक चेतावनी देता है:

BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR: आदिम मान अनियंत्रित है और TestTernary.main (स्ट्रिंग []] में टर्नरी ऑपरेटर के लिए coerced है

एक लिपटे हुए आदिम मूल्य को अनबॉक्स किया जाता है और एक सशर्त टर्नरी (बी 1! ई 1: ई 2 ऑपरेटर) के मूल्यांकन के भाग के रूप में दूसरे आदिम प्रकार में परिवर्तित किया जाता है। जावा जनादेश का शब्दार्थ यह है कि यदि e1 और e2 सांख्यिक मानों से लिपटे हुए हैं, तो मान अनबॉक्स और रूपांतरित / उनके सामान्य प्रकार के लिए coerced हैं (उदाहरण के लिए, यदि e1 प्रकार का है तो Integer और e2 प्रकार फ्लोट का है, तो e1 अपरिवर्तित है, परिवर्तित हो जाता है) एक अस्थायी बिंदु मान, और बॉक्सिंग। JLS धारा 15.25 देखें।

बेशक, फाइंडबग्स ने चेतावनी दी है कि Integer.valueOf (1) नए इंटेगर (1) की तुलना में अधिक कुशल है, लेकिन हर कोई पहले से ही जानता है।

या इस तरह एक उदाहरण:

 Integer n = flag ? 1 : null; 

यदि ध्वज सेट नहीं है तो लेखक n को n में रखना चाहता है। क्या आपको लगता है कि यह काम करेगा? हां। लेकिन जटिल करें:

 Integer n = flag1 ? 1 : flag2 ? 2 : null; 

ऐसा लगेगा कि बहुत अंतर नहीं है। हालाँकि, अब, यदि दोनों ध्वज साफ़ हो जाते हैं, तो यह रेखा NullPointerException को फेंकती है। सही टर्नरी ऑपरेटर के लिए विकल्प इंट और अशक्त हैं, इसलिए परिणामस्वरूप प्रकार पूर्णांक है। बाईं ओर के विकल्प इंट और इंटीगर हैं, इसलिए जावा नियमों के अनुसार, परिणाम अंतर है। ऐसा करने के लिए, आपको intValue को कॉल करके अनबॉक्सिंग करने की आवश्यकता होती है, जो एक अपवाद फेंकता है। कोड इसके बराबर है:

 Integer n; if( flag1 ) n = Integer.valueOf(1); else { if( flag2 ) n = Integer.valueOf(Integer.valueOf(2).intValue()); else n = Integer.valueOf(((Integer)null).intValue()); } 

यहां FindBugs दो संदेश प्रदर्शित करता है, जो एक त्रुटि पर संदेह करने के लिए पर्याप्त हैं:

BX_UNBOXING_IMMEDIATELY_REBOXED: बॉक्सिंग मान अनबॉक्स किया गया है और फिर तुरंत TestTernary.main (स्ट्रिंग []) में रीबॉक्स किया गया है
NP_NULL_ON_SOME_PATH: TestTernary.main (स्ट्रिंग []] में अशक्त संभावित अशक्त सूचक नल
स्टेटमेंट की एक शाखा है, जिसे यदि निष्पादित किया जाता है, तो गारंटी देता है कि एक शून्य मान dereferenced जाएगा, जो कोड निष्पादित होने पर NullPointerException उत्पन्न करेगा।

खैर, इस विषय पर अंतिम उदाहरण:

 double[] vals = new double[] {1.0, 2.0, 3.0}; double getVal(int idx) { return (idx < 0 || idx >= vals.length) ? null : vals[idx]; } 

अप्रत्याशित रूप से, यह कोड काम नहीं करता है: एक समारोह कैसे एक आदिम प्रकार के रिटर्न को शून्य कर सकता है? यह आश्चर्यजनक है कि यह बिना किसी समस्या के संकलन करता है। खैर, यह क्यों संकलन करता है - आप पहले से ही समझते हैं।

DateFormat

जावा में दिनांक और समय को प्रारूपित करने के लिए, उन कक्षाओं का उपयोग करने की सिफारिश की जाती है जो DateFormat इंटरफ़ेस को लागू करते हैं। उदाहरण के लिए, यह इस तरह दिखता है:

 public String getDate() { return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()); } 

अक्सर एक वर्ग समान प्रारूप का पुन: उपयोग करता है। कई लोग अनुकूलन के विचार के साथ आएंगे: जब आप सामान्य उदाहरण का उपयोग कर सकते हैं तो हर बार एक प्रारूप ऑब्जेक्ट क्यों बनाएं?

 private static final DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); public String getDate() { return format.format(new Date()); } 

यह बहुत सुंदर और शांत है, लेकिन दुर्भाग्य से यह काम नहीं करता है। यह अधिक सटीक रूप से काम करता है, लेकिन कभी-कभी टूट जाता है। तथ्य यह है कि DateFormat के लिए प्रलेखन कहता है :

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

और यह सच है अगर आप SimpleDateFormat के आंतरिक कार्यान्वयन को देखते हैं। प्रारूप () विधि को निष्पादित करने की प्रक्रिया में, ऑब्जेक्ट कक्षा के क्षेत्रों को लिखता है, इसलिए दो धाराओं से SimpleDateFormat का एक साथ उपयोग गलत परिणाम के लिए कुछ संभावना के साथ ले जाएगा। इस बारे में FindBugs क्या लिखते हैं:

STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE: TestDate.getDate में स्थैतिक java.text.DateFormat की विधि को कॉल करें ()
जैसा कि JavaDoc बताता है, DateFormats बहुदलीय उपयोग के लिए स्वाभाविक रूप से असुरक्षित हैं। डिटेक्टर ने DateFormat के एक उदाहरण के लिए एक कॉल पाया है जो एक स्थिर क्षेत्र के माध्यम से प्राप्त किया गया है। यह संदिग्ध लग रहा है।

इस बारे में अधिक जानकारी के लिए सन बग # 6231579 और सन बग # 6178997 देखें ।

बिगडेसीमल के नुकसान

यह जानने के बाद कि बिगडेसिमल वर्ग आपको मनमानी सटीकता के भिन्नात्मक संख्याओं को संग्रहीत करने की अनुमति देता है, और यह देखते हुए कि इसमें डबल से एक कंस्ट्रक्टर है, कुछ तय करेंगे कि सब कुछ स्पष्ट है और इस तरह से किया जा सकता है:

 System.out.println(new BigDecimal(1.1)); 

कोई भी वास्तव में ऐसा करने से मना करता है, केवल परिणाम अप्रत्याशित लग सकता है: 1.100000000000000088817841970012523233890533447265625। ऐसा इसलिए होता है क्योंकि IEEE754 प्रारूप में एक आदिम डबल संग्रहीत किया जाता है, जिसमें 1.1 का पूरी तरह से सटीक रूप से प्रतिनिधित्व करना असंभव है (बाइनरी नोटेशन में, एक अनंत आवधिक अंश प्राप्त होता है)। इसलिए, 1.1 के करीब अधिकतम मूल्य वहां संग्रहीत किया जाता है। और BigDecimal का निर्माता (डबल), इसके विपरीत, ठीक काम करता है: यह आदर्श रूप से IEEE754 में दी गई संख्या को दशमलव में बदल देता है (अंतिम बाइनरी अंश हमेशा अंतिम दशमलव के रूप में प्रतिनिधित्व करने योग्य होता है)। यदि आप ठीक 1.1 को बिगडेसिमल के रूप में प्रस्तुत करना चाहते हैं, तो आप या तो new BigDecimal("1.1") या BigDecimal.valueOf(1.1) लिख सकते हैं। BigDecimal.valueOf(1.1) । यदि आप तुरंत नंबर का उत्पादन नहीं करते हैं, लेकिन इसके साथ कुछ संचालन करते हैं, तो आप यह नहीं समझ सकते हैं कि त्रुटि कहाँ से आती है। फाइंडबग्स एक चेतावनी जारी करता है DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE, जो एक ही सलाह देता है।

और यहाँ एक बात और है:

 BigDecimal d1 = new BigDecimal("1.1"); BigDecimal d2 = new BigDecimal("1.10"); System.out.println(d1.equals(d2)); 

वास्तव में, डी 1 और डी 2 एक ही संख्या है, लेकिन रिटर्न के बराबर है, क्योंकि यह न केवल संख्या के मूल्य की तुलना करता है, बल्कि वर्तमान क्रम (दशमलव स्थानों की संख्या) भी है। यह दस्तावेज़ीकरण में लिखा गया है, लेकिन कुछ इस तरह के एक परिचित विधि के लिए प्रलेखन को बराबर के रूप में पढ़ेंगे। ऐसी समस्या तुरंत सामने नहीं आ सकती है। दुर्भाग्य से, फाइंडबग्स ने खुद इस बारे में चेतावनी नहीं दी है, लेकिन इसके लिए एक लोकप्रिय विस्तार है - fb-contrib , जिसमें इस बग को ध्यान में रखा गया है:

MDM_BIGDECIMAL_EQUALS

दो java.math.BigDecimal संख्याओं की तुलना करने के लिए बराबर () कहा जा रहा है। यह आम तौर पर एक गलती है, क्योंकि दो बिगडिमल ऑब्जेक्ट केवल समान हैं यदि वे मूल्य और पैमाने दोनों में समान हैं, तो यह 2.0 के बराबर 2.00 के बराबर नहीं है। गणितीय समानता के लिए BigDecimal वस्तुओं की तुलना करने के लिए इसके बजाय ComparTo () का उपयोग करें।

लाइन फीड और प्रिंटफ

अक्सर, प्रोग्रामर जिन्होंने सी के बाद जावा पर स्विच किया था, वे PrintStream.printf (साथ ही PrintWriter.printf , आदि) को खोजकर खुश हैं। जैसे, ठीक है, मुझे पता है कि, सी की तरह, आपको कुछ भी नया सीखने की जरूरत नहीं है। वास्तव में मतभेद हैं। उनमें से एक लाइन फीड में है।

सी भाषा में पाठ और बाइनरी धाराओं में एक विभाजन है। किसी भी तरह से पाठ स्ट्रीम में वर्ण '\ n' का आउटपुट स्वचालित रूप से सिस्टम-निर्भर लाइन फ़ीड (विंडोज पर "\ r \ n") में परिवर्तित हो जाएगा। जावा में ऐसा कोई अलगाव नहीं है: आपको वर्णों के सही अनुक्रम को आउटपुट स्ट्रीम में पास करना होगा। यह स्वचालित रूप से किया जाता है, उदाहरण के लिए, PrintStream.println परिवार के तरीकों से। लेकिन प्रिंटफ का उपयोग करते समय, प्रारूप स्ट्रिंग में '\ n' पास करना सिर्फ '\ n' है, न कि सिस्टम-निर्भर लाइन फीड। उदाहरण के लिए, निम्नलिखित कोड लिखें:

 System.out.printf("%s\n", "str#1"); System.out.println("str#2"); 

परिणाम को एक फ़ाइल पर पुनर्निर्देशित करने के बाद, हम देखेंगे:

इस प्रकार, आप एक धागे में लाइन फीड का एक अजीब संयोजन पा सकते हैं, जो गन्दा दिखता है और कुछ पार्सर को फाड़ सकता है। आप लंबे समय तक त्रुटि को नोटिस नहीं कर सकते हैं, खासकर यदि आप मुख्य रूप से यूनिक्स सिस्टम पर काम करते हैं। प्रिंटफ का उपयोग करके सही लाइन फीड डालने के लिए, विशेष प्रारूप चरित्र "% n" का उपयोग किया जाता है। इस बारे में FindBugs क्या लिखते हैं:

VA_FORMAT_STRING_USES_NEWLINE: प्रारूप स्ट्रिंग को TestNewline.main (स्ट्रिंग []) में \ n के बजाय% n का उपयोग करना चाहिए

इस प्रारूप स्ट्रिंग में एक नई पंक्ति वर्ण (\ n) शामिल है। प्रारूप स्ट्रिंग में, आमतौर पर% n का उपयोग करना बेहतर होता है, जो प्लेटफ़ॉर्म-विशिष्ट लाइन विभाजक का उत्पादन करेगा।

शायद कुछ पाठकों के लिए उपरोक्त सभी लंबे समय से ज्ञात हैं। लेकिन मुझे पूरा यकीन है कि उनके लिए स्थैतिक विश्लेषक से एक दिलचस्प चेतावनी है जो उन्हें इस्तेमाल की जाने वाली प्रोग्रामिंग भाषा की नई विशेषताओं को खोलेगी।