इसे पोस्ट करने का यह एक अच्छा समय है, ठीक जावा 19 के रिलीज पर। हां, एक और "मेरी भाषा बेहतर है" पोस्ट। नहीं, मैं इसे लिखना नहीं चाहता था। लेकिन कभी-कभी लोगों का बुरा प्रक्षेपण मुझसे बेहतर हो जाता है। इस मामले में, पोस्ट एक टिप्पणी के रूप में शुरू हुई और मैंने इसे पोस्ट में बदलने का निर्णय लिया। इस पोस्ट के साथ इसे मजबूत किया गया था जो ज्यादातर क्वार्कस के बारे में शिकायत करता है (अगर मैं जोड़ सकता हूं तो कुछ गलत है)।
पहला लेख ज्यादातर बकवास और पुराना क्लिकबैट है। मैं इसे निम्नलिखित दावों में आपके साथ जोड़ दूंगा:
[]
के लिए और किसी भी चीज़ पर +
के लिए गुम ऑपरेटर ओवरलोडिंग
दूसरे लेख में ऐसी शिकायतें हैं जो जेवीएम में जकार्ता ईई और सामान्य प्रोग्रामर सौंदर्यशास्त्र से अधिक संबंधित हैं। विशेष रूप से सत्यापन और इसी तरह के दावों के लिए एनोटेशन का उपयोग। यह एक बेहतर जानकारी वाला लेख है, लेकिन इसमें कुछ खामियां हैं जिन्हें मैं अंत में संबोधित करूंगा।
आधुनिक जावा के लिए गेटर्स और सेटर्स आवश्यक नहीं हैं। जावा 14 के बाद से हमारे पास रिकॉर्ड हैं और इसके विपरीत कुछ दावों के बावजूद लोम्बोक अभी भी अच्छा है। एकमात्र बिंदु जहां हमें गेटटर/सेटर्स की आवश्यकता होगी, वह बहुत विशिष्ट सेटिंग्स (जैसे जेपीए) में है, जहां फिर से, लोम्बोक समस्या को पूरी तरह हल करता है।
लेख जावा में वाक्यात्मक चीनी सुविधाओं की कमी पर एक तीखा बनाता है। यह जानबूझकर है। यदि आप नवीनतम सिंटैक्स बारीकियों में रुचि रखते हैं, तो आप कोटलिन को देख सकते हैं। जावा "धीमा और स्थिर" के बारे में है। यह एक अच्छी बात है और जावा की लंबी उम्र के पीछे मुख्य कारण है।
आधुनिक जावा में स्विच, var, मल्टीलाइन स्ट्रिंग्स और बहुत कुछ में पैटर्न शामिल हैं। कुछ आगामी सुविधाओं में स्ट्रिंग टेम्पलेट शामिल हैं। स्ट्रिंग टेम्पलेट समर्थन में कुछ समय लगता है क्योंकि जावा "इसे सही करना" चाहता है। इसके लिए एपीआई स्तर में कुछ समर्थन है (और कुछ समय के लिए रहा है)। यह प्रदर्शनकारी नहीं है। स्ट्रिंग टेम्प्लेट का लक्ष्य एक कट्टरपंथी अतिव्यापी वाक्यविन्यास बनाना है जो सामान की अनुमति देगा :
ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}";
अद्यतन: इस पोस्ट के प्रकाशन के बाद से डेवलपर्स ने गलती से मान लिया है कि उपरोक्त कोड एक SQL इंजेक्शन भेद्यता है। यह नहीं है। यह स्ट्रिंग प्रतिस्थापन की तरह दिखता है लेकिन यह कोड है जो पैरामीटरयुक्त SQL कॉल उत्पन्न करने के लिए उस वाक्यविन्यास का उपयोग करता है।
ध्यान दें कि name
एक चर है जिसे संकलक जांच करेगा और गतिशील रूप से दायरे से प्राप्त करेगा!
DB
को डेवलपर द्वारा कस्टम कार्यान्वित किया जा सकता है और इसे "अंतर्निहित" होने की आवश्यकता नहीं है ताकि आप जटिल टेम्पलेट्स को सही जगह पर बना सकें।
लेकिन आइए आज जावा के बारे में बात करते हैं, न कि 6 महीने में आने वाले जावा के बारे में। एपेंड का उपयोग करना एक दशक या उससे अधिक समय से String
के लिए अनुशंसित नहीं है। +
का उपयोग करें जो सबसे अधिक प्रदर्शन करने वाला और पढ़ने में आसान है। संग्रह के बारे में, get()
और []
के बीच का अंतर वस्तुतः चार वर्ण है। वे किरदार बहुत मायने रखते हैं। हम इसे आसानी से ओवरराइड कर सकते हैं। हम अर्थ संबंधी अंतरों को भी समझ सकते हैं। जावा सरणियाँ बहुत तेज़ हैं, कई मामलों में मूल गति तेज़ है। संग्रह उतने तेज़ नहीं हो सकते हैं, यह तथ्य कि हम इसे यहाँ तुरंत देख सकते हैं, बहुत मूल्यवान है।
तथ्य यह है कि ऑपरेटरों को अतिभारित नहीं किया जा सकता है, यह एक बड़ा लाभ है। अगर मुझे a + b
दिखाई देता है, तो मुझे पता है कि यह या तो एक स्ट्रिंग है या एक संख्या है, न कि कोई छिपी हुई विधि। यह जावा की सबसे बड़ी ताकतों में से एक है और इसका एक कारण यह लगभग 30 वर्षों से लोकप्रिय है जबकि अन्य भाषाओं को किनारे कर दिया गया है। जावा के सिंटैक्स को बड़े पैमाने पर पढ़ने के लिए डिज़ाइन किया गया है। जब आपके पास कोड की 1M लाइनों या 100k के साथ कोई प्रोजेक्ट होता है, तो समस्याएं बदल जाती हैं। इस बिंदु पर यह पता लगाना कठिन है कि मॉड्यूल Y में प्रोग्रामर X एक ऑपरेटर को गलत तरीके से ओवरराइड करता है जब आप किसी समस्या को डीबग कर रहे होते हैं। उस समय वाक्य-विन्यास सरल होना चाहिए और शुरू में आपके द्वारा सहेजी गई किसी भी छोटी लागत का भुगतान 10x ब्याज के साथ किया जाएगा। कोड के रूप में सरल फ़्लिप की परिभाषा अधिक जटिल और उम्र हो जाती है। उस टूलिंग की शक्ति को बड़े पैमाने पर सख्त सरल कोड को पार्स करने के लिए जोड़ें और यह और भी बड़ा लाभ बन जाता है।
चेक किए गए अपवाद वैकल्पिक हैं। लेकिन वे जावा में सबसे अच्छी सुविधाओं में से एक हैं। इतना कोड अप्रत्याशित रूप से विफल हो जाता है। जब आप एक शौक के रूप में सामान बना रहे हों तो यह ठीक हो सकता है। जब आप एक पेशेवर एप्लिकेशन बनाना चाहते हैं तो आपको हर त्रुटि को संभालने की आवश्यकता होती है। चेक किए गए अपवाद आपको उस बकवास से बचने में मदद करते हैं। लोग आलस्य के कारण जाँच अपवादों से घृणा करते हैं। जावा आपको खुद से बचाता है।
ऐसा कोई मामला नहीं होना चाहिए जहां मैं एक नेटवर्क कनेक्शन, एक डीबी कनेक्शन, एक फाइल खोलता हूं, आदि और संभावित त्रुटि को संभालने की आवश्यकता नहीं है। मैं इसे पंट कर सकता हूं लेकिन फिर चेक किए गए अपवादों ने मुझे इसे कहीं न कहीं पंट करने के लिए मजबूर किया। यह एक अद्भुत विशेषता है।
मुझे मेवेन और ग्रैडल के साथ बहुत सारी समस्याएं हैं। लेकिन जब आप इसकी तुलना किसी भी अन्य निर्भरता प्रणाली से करते हैं, तो उस पर कुछ मिलेज वे बहुत अच्छा कर रहे हैं। उनके पास समस्याएं हैं, लेकिन आप उनकी तुलना किसी युवा जैसे कार्गो से नहीं कर सकते, जिसकी तुलना में लगभग कोई पैकेज नहीं है। मावेन सेंट्रल 27 टेराबाइट जार और 496 बिलियन अनुरोधों के साथ विशाल है। यह पूरी तरह से टिक जाता है और इसमें लगभग कोई डाउनटाइम नहीं होता है।
एनपीएम जैसे अन्य उपकरण पूरी तरह से मेवेन की ताकत का प्रदर्शन करते हैं। यदि मावेन में निर्भरता एक समस्या है तो एनपीएम में 100x समस्या है और कोई पर्यवेक्षण नहीं है। जैसे-जैसे ये चीजें बढ़ती हैं, जटिलताएं होती हैं। विशेष रूप से बाजार में मेवेन के कई संस्करणों के साथ। हालाँकि, मावेन और ग्रेडल के लिए जो चीजें चल रही हैं उनमें से एक टूलींग है। कई मामलों में आईडीई मुद्दों को हल करने में मदद करते हैं और बॉक्स के ठीक बाहर फिक्स ढूंढते हैं।
दूसरा लेख अधिक दिलचस्प है और कुछ हद तक मैं सहमत हूं। जावा डेवलपर्स हर समस्या को अधिक जटिल समस्या में बदल देते हैं। कुछ मामलों में यह आवश्यक है, जावा प्रोग्रामिंग प्लेटफॉर्म का 800 पाउंड का गोरिल्ला है और इसके समाधान अक्सर ओवर-इंजीनियर होते हैं। यह कम संचालित की तुलना में बेहतर होता है, लेकिन इसकी कीमत होती है।
लेख ने एक दिलचस्प उदाहरण पेश किया जो आकस्मिक पर्यवेक्षक के लिए "सही बात" जैसा लगता है लेकिन समस्याग्रस्त है।
@NotNull @Email String noReplyEmailAddress
लेखक का दावा है कि यह खराब है और किसी को कस्टम टाइपिंग लागू करनी चाहिए जैसे:
public record EmailAddress(String value) { public EmailAddress { // We could've used an Either data type, ofc; Objects.requireNonNull(value); // regexp could be better if (!value.matches("^[^@\\s]+@\\S+$")) throw new IllegalArgumentException( String.format("'%s' is not a valid email address", value)); } }
जावा में यह पूरी तरह से संभव है क्योंकि उपरोक्त कोड वैध जावा कोड है। लेकिन इसमें कई समस्याएं हैं, यही वजह है कि हमारे पास बीन सत्यापन है।
परिणामस्वरूप, एनोटेशन अजीब लग सकते हैं और टाइपिंग को लागू नहीं करते हैं। यह सच है। लेकिन वे प्रदर्शन और शक्ति बढ़ाते हैं। उनके उपयोग के पीछे बहुत सोच और सामान्य ज्ञान है। मुझे लेखक की बात मिलती है, मैं भी एक बड़ा आईओसी प्रशंसक नहीं हूं, लेकिन इस विशिष्ट मामले में वह गलत है।
इस लेख ने रक्षात्मक पर बहुत अधिक समय बिताया। यह गियर स्विच करने का समय है। जावा लगभग 30 वर्षों से है और अभी भी जावा 1.0 के अनुकूल है। यह शानदार और बेजोड़ है!
इसके रूढ़िवादी दृष्टिकोण की शक्तियों में से एक यह है कि यह आश्चर्यजनक "हुड के तहत" अनुकूलन कर सकता है, आप में से किसी ने भी यह नहीं देखा कि क्या हुआ। जावा 9 ने पूरी तरह से मेमोरी में स्ट्रिंग्स के प्रतिनिधित्व के तरीके को पूरी तरह से बदल दिया , और रैम के उपयोग को काफी कम कर दिया। इसी तरह लूम जावा सिंक्रोनस एप्लिकेशन के थ्रूपुट को बढ़ावा देगा। वल्लाह संग्रह प्रदर्शन में और सुधार करेगा और वस्तु/आदिम विभाजन को एकीकृत करेगा। पनामा अंततः हमें जेएनआई से छुटकारा दिलाएगा और देशी कोड के साथ एकीकरण की प्रक्रिया को और अधिक सुखद बना देगा।
अच्छी बात यह है कि जेवीएम एक बड़ा तंबू है। यदि आप जावा के प्रशंसक नहीं हैं, तो कोटलिन या स्काला आपके स्वाद के अनुरूप हो सकता है। जेवीएम का लाभ सार्वभौमिक रूप से लागू होता है और मैंने यहां जिन अधिकांश सुविधाओं का उल्लेख किया है, वे हमारे पूरे संयुक्त पारिस्थितिकी तंत्र को लाभान्वित करेंगी।
यह कहानी सबसे पहले यहाँ प्रकाशित हुई थी।