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

उनकी रिपोर्ट दुनिया भर में जावा सम्मेलन खोलती है। यह वह है जो समुदाय के सवालों के जवाब देता है, YouTube पर स्प्रिंग टिप्स करता है, यह उसका "इस सप्ताह वसंत में" है जिसे हम हर हफ्ते और बहुत कुछ पढ़ते हैं।

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

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

प्रतिभागियों

जोश लॉन्ग, स्प्रिंग डेवलपर पिवसल में एडवोकेट

एवगेनी ट्रिफोनोव, ओलेग चिरुखिन - जुगोव ग्रुप के संपादक

हर कोई जानता है कि आप बहुत यात्रा करते हैं, लेकिन यह दिलचस्प होगा यदि आप कुछ आंकड़े दे सकते हैं - पिछले साल आपने कितने सम्मेलन में भाग लिया, आपने कितनी उड़ानें और पसंद कीं।

अच्छा सवाल है। मेरे पास एक तालिका है जो वर्ष के लिए मेरी सभी बैठकों को रिकॉर्ड करती है। मेरे सहायक, ताशा, मुझे अनुसूची और इस तालिका को व्यवस्थित करने में मदद करते हैं। तो, चलो इस टैबलेट को फोन पर खोलें ... दो सौ चालीस। 2018 में, इस समय, मैंने 240 विभिन्न कार्यक्रमों में भाग लिया। इनमें से कुछ बैठकें ऑनलाइन (हमारी तरह) होती हैं, लेकिन मुझे ज्यादातर के लिए उड़ान भरनी होती है। इस वर्ष में, मैंने आधा मिलियन मील की दूरी पर उड़ान भरी। मुझे पृथ्वी से चंद्रमा तक की दूरी की जांच करने दें ... यह 239 हजार मील की दूरी पर है, ताकि मैं चंद्रमा पर वापस जा सकूं।

"चंद्रमा से और वसंत से वापस।" टॉल्किन की पुस्तक के लिए अच्छा शीर्षक।

क्या एयरलाइंस आपको विशेष ऑफ़र देती है क्योंकि आप इतना उड़ते हैं?

खैर, मैं सेवा के बारे में शिकायत नहीं करता। मैं अक्सर यूनाइटेड एयरलाइंस के साथ उड़ान भरता हूं और उनका ग्लोबल सर्विसेज प्रोग्राम है। आप केवल एक निमंत्रण प्राप्त करके वहां पहुंच सकते हैं - आप खुद इसके लिए नहीं पूछ सकते हैं, और इसके क्या मापदंड हैं, यह अज्ञात है। हर साल वे उन लोगों को आमंत्रित करते हैं जो अक्सर उड़ान भरते हैं। पिछले साल, किसी ने कहा कि वे दुनिया भर में सबसे अधिक ग्राहकों का 1% का चयन करते हैं। या हो सकता है कि वे लागत की राशि से फ़िल्टर करें। एक तरीका या दूसरा, वे मेरे साथ बहुत अच्छा व्यवहार करते हैं। यह अच्छा है। लेकिन इस मामले में भी, मुझे लगता है, ज्यादातर लोगों के लिए, उड़ानें एक बोझ हैं। यह निश्चित रूप से मुझे चिंतित करता है। मैं खुद उड़ानों के लिए नहीं उड़ता, बल्कि उन लोगों से मिलने के लिए आता हूं जो स्प्रिंग का उपयोग करते हैं। अगर ऐसा कोई मौका होता तो मैं टेलीपोर्ट करता। जीवन बहुत सरल और अधिक दिलचस्प होगा।

हाइपरलूप की प्रतीक्षा करने का अच्छा कारण।

हां, लेकिन इसके लिए लंबा इंतजार करना होगा।

चलो वसंत के करीब एक विषय के बारे में बात करते हैं। आप दुनिया भर के लोगों के साथ इसके बारे में बात करते हैं - क्या इसकी व्यापकता में कोई क्षेत्रीय अंतर हैं?

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

हाँ यह सच है।

और चीन में, MyBatis बहुत लोकप्रिय है। संयुक्त राज्य अमेरिका और यूरोप में, मैंने इसे 10 वर्षों तक नहीं देखा है, और चीन में यह वसंत के रूप में आम है। और, वास्तव में, MyBatis के साथ कुछ भी गलत नहीं है, यह तेज और शक्तिशाली है - तो इसका उपयोग क्यों नहीं करें?

हमने एक परियोजना की जिसमें MyBatis ने ग्रिडगैन के साथ काम किया, यह अंदर है।

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

आप वसंत परियोजनाओं के लिए निर्णायक डेवलपर एडवोकेट हैं। व्यवहार में इसका क्या अर्थ है? वास्तव में आप क्या कर रहे हैं?

एक कठिन सवाल। डेवलपर एडवोकेट की अवधारणा ने Apple और विशेष रूप से, Microsoft के लिए धन्यवाद फैलाया है। यह लगभग 30 साल पहले शुरू हुआ था, जब माइक्रोसॉफ्ट ने महसूस किया कि यह डेवलपर्स थे जिनके पास असली ताकत थी। यदि आप चाहते हैं कि आपका प्लेटफ़ॉर्म सफल और उपयोगी हो, तो आपको इस प्लेटफ़ॉर्म पर नई मूल्यवान चीज़ें बनाने के लिए डेवलपर्स की आवश्यकता होगी। तदनुसार, आपको अपने प्लेटफ़ॉर्म के लाभों के बारे में उन्हें समझाना होगा। Microsoft ने कई अलग-अलग तरीकों से डेवलपर्स को प्रेरित करने की कोशिश शुरू की। उन्होंने विजुअल स्टूडियो को बहुत सस्ता बना दिया, यानी उन्होंने किफायती उपकरण उपलब्ध कराए। उन्होंने बहुत सारे दिलचस्प एपीआई बनाए जो आप विंडोज के तहत काम कर सकते हैं। सामान्य तौर पर, Microsoft ने महसूस किया कि समुदाय के साथ सहयोग करना आवश्यक था। लोग सॉफ्टवेयर पर भरोसा नहीं करते हैं, लेकिन अन्य लोग। लोगों को सॉफ्टवेयर से कोई भावनात्मक लगाव नहीं है। आप जितना चाहें कल्पना कर सकते हैं कि आप बस अपने होटल के कमरे में एकांत में एक कार्यक्रम लिखकर प्रसिद्ध हो जाएंगे, और जिस किसी को भी इसकी आवश्यकता होगी, वह स्वयं दस्तावेज ढूंढेगा। लेकिन वास्तव में ऐसा आमतौर पर नहीं होता है। मेरी जिम्मेदारियों का एक महत्वपूर्ण हिस्सा समुदाय के लोगों के साथ संवाद कर रहा है। मैं सुनता हूं कि लोग क्या कहते हैं और इसे डेवलपर्स के लिए लाते हैं, और फिर उस समुदाय को पास करते हैं जो डेवलपर्स कहते हैं। दूसरे शब्दों में, मैं एक तरह का वाहन हूं।

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

समस्या यह है कि यह दृष्टिकोण ठीक नहीं है। सभी डेवलपर्स के लिए अपना आधा समय यात्रा, चैटिंग और मीटिंग में बिताना असंभव है। जिस समय मैं टीम में शामिल हुआ, मैं पहले से ही स्प्रिंग के लिए कोड लिख रहा था, क्योंकि यह एक ओपन सोर्स प्रोजेक्ट है। इसके अलावा, मैंने पहले से ही किताबें प्रकाशित की थीं, मैंने लेख लिखे और प्रस्तुतियाँ दीं। इसलिए मैंने पहले से ही समुदाय के लिए स्प्रिंग को यथासंभव सर्वोत्तम रूप से पेश करने और इसे जानने के लिए यथासंभव अधिक से अधिक लोगों को देने का प्रयास किया। इसलिए, स्प्रिंग टीम ने मुझे ऐसा करने के लिए आमंत्रित किया, लेकिन निरंतर आधार पर और पैसे के लिए। मुझे लगता है कि मैं 80% डेवलपर एडवोकेट और 20% प्रोग्रामर हूं, जबकि बाकी डेवलपर एडवोकेट टीम 20% और 80% प्रोग्रामर हैं।

सब सब में, मेरा काम समुदाय के साथ संपर्क में रखना है, और ऐसा करने के कई अलग-अलग तरीके हैं। मैं अपनी छठी पुस्तक लिख रहा हूं, इसे द रिएक्टिव स्प्रिंग बुक कहा जाता है; मेरे पहले वाले को O'Reilly ने Cloud Native Java नाम से प्रकाशित किया था। मैंने बहुत सारे वीडियो ट्यूटोरियल बनाए जो आप सफारी बुक्स ऑनलाइन पर देख सकते हैं, जिनमें से प्रत्येक में 4-5 घंटे लगते हैं। इसके अलावा, प्रत्येक बुधवार को मैं YouTube पर स्प्रिंग टिप्स वीडियो पोस्ट करता हूं, जिनमें से प्रत्येक पारिस्थितिकी तंत्र के एक विशिष्ट संकीर्ण पहलू के लिए समर्पित है। वे आम तौर पर 45 मिनट से एक घंटे तक रहते हैं, हर साल मैं कम से कम दो सीज़न करता हूं, कभी-कभी तीन। इस प्रकार, हर साल दो साल में, मैं सम्मेलन में पूरी रिपोर्ट के लिए पर्याप्त सामग्री तैयार करता हूं। जनवरी 2011 में शुरू हुआ, हर मंगलवार, बिना किसी अपवाद के, मैं एक नया ब्लॉग प्रविष्टि बनाता हूं, "इस सप्ताह वसंत में" , जिसमें मैं पारिस्थितिकी तंत्र में सभी सबसे दिलचस्प समीक्षा करता हूं। मेरे पास अन्य ब्लॉग भी हैं, पिछले दो शाम मैं बस यही कर रहा हूं। इसके अलावा, मैं कोड भी लिखता हूं और सम्मेलनों में बोलता हूं। इसलिए मेरे काम में विविध प्रकार की गतिविधियाँ शामिल हैं - लेकिन मैं खुद को सिर्फ एक चीज़ तक सीमित कर सकता था। ऐसे लोग हैं जो सिर्फ ब्लॉग बनाते हैं या सिर्फ वीडियो बनाते हैं, और वे इसे बहुत अच्छी तरह से करते हैं। कुछ भी यात्रा नहीं करते हैं, लेकिन ऑनलाइन सेमिनार करते हैं। मेरा दृष्टिकोण दूसरों से अलग है, लेकिन, आखिरकार, यह सभी गतिविधि एक ही लक्ष्य का पीछा करती है।

वैसे, मेरी जिम्मेदारियों में ट्यूटोरियल बनाना, ब्लॉगिंग करना आदि भी शामिल हैं। मेरे लिए यह बहुत कठिन है और समय की एक मनमानी राशि ले सकता है। यह आपको कितना कठिन है? आइए बताते हैं कि एक स्प्रिंग टिप्स वीडियो तैयार करने में कितना समय लगता है?

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

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

वर्तमान में स्प्रिंग में कितनी परियोजनाएँ मौजूद हैं?

अच्छा सवाल है। मुझे लगता है कि कुछ दर्जन। बहुत विशिष्ट मॉड्यूल हैं, जिनमें से कुछ समुदाय द्वारा विकसित किए गए हैं, कुछ पुस्टल या अन्य बड़ी कंपनियों में स्प्रिंग टीम द्वारा। Google में Google GCP के लिए सभी समर्थन, Microsoft Azure के लिए समर्थन - Microsoft में बनाए गए थे। लेकिन बहुत कुछ - जैसे MyBatis, उदाहरण के लिए - समुदाय द्वारा विकसित किया जा रहा है। इसके अलावा, हमारे पास अलग-अलग मॉड्यूल हैं, उदाहरण के लिए, स्प्रिंग डेटा Neo4j, Neo4j ग्राफ डेटाबेस के लिए एक मॉड्यूल। यह स्प्रिंग डेटा परियोजना का हिस्सा है, लेकिन यह Neo4j के सहयोग से किया गया था, उन्होंने इस परियोजना पर मुख्य काम किया, वह सिर्फ हमारे गिट रिपॉजिटरी में रहते थे। ऐसे कई उदाहरण हैं।

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

और इस सभी प्रकार की परियोजनाओं में उपयोगकर्ताओं को कैसे समझा जाए? क्या कुछ सामान्य संरचना या विचार है?

सबसे अधिक संभावना है, आपको सभी परियोजनाओं की आवश्यकता नहीं होगी। अपना लक्ष्य निर्धारित करें, और उसके आधार पर वांछित परियोजना का चयन करें। मुझे यह पसंद नहीं है जब लोग "स्प्रिंग सीखने" की कोशिश करते हैं - यह एक व्यर्थ अभ्यास है। प्रश्न को इस तरह से प्रस्तुत किया जाना चाहिए: मुझे लिखने की जरूरत है, एक REST API। मेरा पहला कदम वसंत के लिए है ।io / guides , जहां आप एक सरल और सस्ती गाइड पा सकते हैं, जिसमें 10-15 मिनट लगते हैं। इसमें वह सब कुछ होगा जो आपको जानना चाहिए: किस कोड को लिखना है, किस फ़ोल्डर में, कैसे करना है IntelliJ या ग्रहण में या किसी अन्य चीज़ में। हम हर चीज को बहुत विस्तार से समझाने की कोशिश करते हैं और कुछ भी छोड़ नहीं देते हैं, क्योंकि हम चाहते हैं कि ये गाइड सभी के लिए सुलभ हों। आप जो भी करते हैं - जेएमएस, नियो 4 जे, सुरक्षा, सर्किट ब्रेकर, काफ्का - हमारे पास प्रत्येक विषय के लिए एक अलग गाइड है। अपने कार्य पर निर्णय लें और उचित मार्गदर्शिका का चयन करें। आपको स्प्रिंग के बारे में नहीं सोचने की ज़रूरत है, लेकिन इस बारे में कि आप अपने सिस्टम को किसके साथ एकीकृत करेंगे - स्प्रिंग केवल एक उपकरण है जो इस एकीकरण की अनुमति देता है। इसलिए, "स्प्रिंग सीखने में" कोई मतलब नहीं है - आपको इसका उपयोग करने की आवश्यकता है अगर यह आपके विशिष्ट कार्य को सरल कर सकता है।

आपकी राय में, स्प्रिंग में कौन-सी परियोजनाएँ सबसे अधिक आशाजनक हैं? या सबसे कम?

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

वास्तव में प्रतिक्रियावाद क्यों?

हमारी हर जगह प्रतिक्रिया है। स्प्रिंग का लाभ यह है कि आप इसके साथ एक परियोजना शुरू और समाप्त कर सकते हैं। इस हफ्ते हमने घोषणा की कि हम फेसबुक आरएसकेट प्रोजेक्ट का समर्थन करेंगे। यह gRPC का एक पूरी तरह से प्रतिक्रियाशील एनालॉग है, लेकिन काफी अधिक लचीला है। यह पब / उप, स्ट्रीमिंग डेटा, क्लाइंट अनुरोध / प्रतिक्रिया के लिए इस्तेमाल किया जा सकता है - सामान्य तौर पर, इसके साथ आप कई अलग-अलग मैसेजिंग पैटर्न लागू कर सकते हैं। और इसका उपयोग फेसबुक पर किया जाता है। दो बंडल हैं, एक C ++ में, दूसरा जावा में। जावा में एक रिएक्टर, हमारे प्रतिक्रियाशील पुस्तकालय का उपयोग करके लिखा गया है। वह Salesforce का उपयोग करता है। बेशक, अन्य विकल्प हैं। क्या आपने Google से जीआरपीसी के बारे में सुना है? यह बहुत ही उच्च गुणवत्ता और दिलचस्प है, लेकिन यह प्रतिक्रियाशील नहीं है, डिफ़ॉल्ट रूप से यह प्रतिक्रियाशील प्रकारों के साथ अच्छी तरह से काम नहीं करता है। Salesforce gRPC में यह खामी नहीं है। उसके पास एक कंपाइलर है जो स्प्रिंग रिएक्टर पर आधारित सेवाएं बनाता है। इसलिए फेसबुक और सेल्सफोर्स दोनों ही रिएक्टर को अपनी जरूरतों के हिसाब से रखने में सक्षम थे।

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

इसके अतिरिक्त, हमने हाल ही में R2DBC के बारे में एक घोषणा की - प्रतिक्रियाशील ड्राइवरों के लिए SQL- आधारित डेटा तक पहुँचने के लिए हमारा एपीआई। प्रतिक्रियाशील JDBC अभी तक मौजूद नहीं है। समस्या यह है कि यदि आप प्रतिक्रियाशील कोड का उपयोग करते हैं, तो आप लॉक का उपयोग नहीं कर सकते। यदि लॉकिंग का उपयोग किया जाता है, तो इस इंटरैक्शन को बढ़ाया जाना चाहिए, जिससे थ्रेड्स की संख्या बढ़ जाएगी। और यह मूल लक्ष्य का खंडन करता है, चूंकि हम थ्रेड्स की संख्या बढ़ाकर स्केलिंग से बचना चाहते हैं - यह बहुत महंगा है। इसलिए, R2DBC एक अमूर्तता प्रदान करता है जो प्रतिक्रियाशील डेटा एक्सेस प्रदान करता है। डेटाबेस ड्राइवर हैं जो शुरू में प्रतिक्रियाशील हैं - उदाहरण के लिए, पोस्टग्रेज। तो आप अन्य चीजों के साथ, पोस्टग्रेज के साथ R2DBC का उपयोग कर सकते हैं और लॉक का उपयोग किए बिना प्रतिक्रियाशील SQL के साथ काम कर सकते हैं, क्योंकि आपके पास थ्रेड्स नहीं हैं। यह पूरा विषय मुझे बेहद दिलचस्प लगता है।

शायद आप अक्सर पूछे जाने वाले कुछ तकनीकी सवालों के जवाब दे सकते हैं? समस्याओं में से एक यह है कि कई स्प्रिंग प्रोजेक्ट्स का उपयोग करते समय, कई एनोटेशन एक साथ होते हैं। यह पता लगाना मुश्किल हो जाता है कि उनमें से प्रत्येक क्या करता है - आप केवल Ctrl दबाए रखते हुए उस पर क्लिक नहीं कर सकते हैं और परिभाषा पर जा सकते हैं। ऐसी स्थिति में कैसे व्यवहार करें?

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

अब थोड़ा ट्रोलिंग सवाल होगा। वसंत के विरोधी अक्सर दावा करते हैं कि यह निम्न-गुणवत्ता की वास्तुकला का कारण है, क्योंकि आप बस कहीं भी और कहीं भी @Autowired उपयोग कर सकते हैं। क्या आप इस राय से सहमत हैं? दस साल पहले, वास्तुकला तीन परतों में बनाई गई थी, मूल्यों को कंस्ट्रक्टर से कंस्ट्रक्टर में स्थानांतरित किया गया था, और डीटीओ बनाए गए थे। वसंत के साथ, आप इस सब से छुटकारा पा सकते हैं। यह अच्छा है या बुरा?

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

स्प्रिंग में, आप काफी स्पष्ट वायरिंग बना सकते हैं। यदि आप चिंतित हैं कि यह स्पष्ट नहीं होगा कि दी गई वस्तु कहां से आई है, तो आप इसे स्वयं बांध सकते हैं। आप एक जावा कॉन्फ़िगरेशन बना सकते हैं जिसमें एक विधि दूसरे को कॉल करेगी, और बुलाया विधि का आउटपुट मान एक बिन होगा - स्प्रिंग इसका ख्याल रखेगा। यहां तक ​​कि जब आप एक ही बिन को बार-बार या हजारों बार कॉल करते हैं, तो आपके पास कभी भी एक लिंक से अधिक नहीं होगा यदि यह ऑब्जेक्ट एक सिंगलटन है। आप चाहते हैं कि सब कुछ स्पष्ट हो - यह किया जा सकता है यदि आप चाहें, तो आप एक और अधिक उबाऊ विकल्प - XML ​​में बदल सकते हैं। लब्बोलुआब यह है कि यदि आप `@ ऑटोवार्ड` का उपयोग नहीं करना चाहते हैं, तो इससे पूरी तरह बचा जा सकता है।

यदि आप सबसे सामान्य तरीके से स्प्रिंग बूट का उपयोग करते हैं, तो आपके पास केवल एक बीन होगा। आप जानते हैं कि आपको `कनेक्शनफैक्टरी` के सेम की आवश्यकता है - इस प्रकार से इंजेक्शन बनाने में कोई समस्या नहीं है। आपके पास अभी भी केवल एक ही वस्तु है, आपके पास एक `कनेक्शन` के लिए दो` कनेक्शनफैक्टरी` नहीं हैं। आपके पास दो हाइबरनेट सत्र नहीं हैं, इसलिए कुछ भी आपको `हाइबरनेट सत्र` को इंजेक्ट करने से रोकता है - यह अभी भी एक ही उदाहरण में मौजूद है। यदि आप चाहते हैं कि सब कुछ स्पष्ट हो, तो आप `@ क्वालीफायर` एनोटेशन का उपयोग कर सकते हैं। इसके साथ, आप चिह्नित करते हैं कि आप किस प्रकार के इंजेक्शन लगाते हैं। इससे विभिन्न बिन कार्यान्वयन को एक-दूसरे से अलग करना संभव होगा। मान लें कि आपके पास एक ऐसी सेवा है जिसके साथ एक जगह पर एप्लिकेशन iTunes के साथ, दूसरे में - अमेज़ॅन के साथ, तीसरे में - एंड्रॉइड प्ले स्टोर के साथ संवाद कर सकता है। यह एक अलग प्रकार की तीन अलग-अलग फलियां होंगी, लेकिन प्रत्येक में एनोटेशन `@ क्वालीफायर` होगा। इसके अलावा, इस एनोटेशन को किसी अन्य एनोटेशन पर लागू किया जा सकता है, इस प्रकार यह सुनिश्चित करता है कि सुरक्षा। आप इस प्रकार को बांधेंगे, और आपके पास इसके ऊपर एक एनोटेशन होगा, और जब बीन बनाई जाएगी, तो इसमें उपभोक्ता की साइट पर `@ क्वालीफायर` एनोटेशन होगा। इस प्रकार, ये एनोटेशन आपको लिंक प्रदान करेगा, और भले ही आपके पास तीन कार्यान्वयन हों, जब प्रोग्राम चल रहा हो, तब भी आप अपनी आवश्यकता का पता लगा सकते हैं।

यही है, सामान्य तौर पर, आपकी राय में, लचीलापन एक सकारात्मक विशेषता है। क्या आप और स्प्रिंग टीम ज़ेन ज़ेन जैसे कुछ मूलभूत सिद्धांतों का पालन करते हैं?

हाँ, का पालन करें। वैसे, मैं 90 के दशक के अंत से पायथन में प्रोग्रामिंग कर रहा हूं, और मैं पायथन ज़ेन का एक बड़ा प्रस्तावक हूं, उनके पास एक बहुत ही सही सामान्य विचार है। आपके प्रश्न के लिए, यहां आपको स्प्रिंग के सह-संस्थापक जुरगेन होलर और परियोजना पर काम करने वाले दूसरे डेवलपर के बारे में बात करने की आवश्यकता है। यह एक स्वीटहार्ट आदमी है, बहुत शांत, सबसे अच्छे में से एक जिसके साथ मुझे संवाद करना था। उसके साथ बात करना बहुत आसान है यदि, उदाहरण के लिए, आप उनसे एक सम्मेलन में मिले थे। उसी समय, उनके पास एक शक्तिशाली बुद्धि है, और वसंत में उनका योगदान बहुत कठिन है। JAX सम्मेलन - बहुत महत्वपूर्ण, हालांकि, निश्चित रूप से, जोकर तक नहीं पहुंचता है :) - ने उन्हें काम के लिए एक विशेष पुरस्कार दिया जो पहले किसी और को नहीं मिला था। आमतौर पर पुरस्कार कुछ विशेष श्रेणी में दिए जाते हैं, लेकिन यह एक श्रेणी के बिना है और केवल जर्गेन के अंतर्गत आता है। जावा इकोसिस्टम में स्प्रिंग एकमात्र ऐसी परियोजना है जिसे 15 वर्षों में फिर से नहीं लिखा गया है - क्योंकि इसकी कोई आवश्यकता नहीं है। जुरगेन का एक बहुत स्पष्ट विचार है कि कैसे मॉड्यूल लिखना है, कैसे प्रकार व्यक्त करना है, सामान्य रूप से - उच्च गुणवत्ता वाले कोड का आधार कैसे बनाया जाए जो दशकों तक रह सकते हैं और यदि आवश्यक हो तो आसानी से बदल सकते हैं। जावा इकोसिस्टम में ऐसी अन्य परियोजनाएँ नहीं हैं। परियोजनाओं का एक महत्वपूर्ण हिस्सा अब मौजूद नहीं है, और यहां तक ​​कि उन लोगों के बीच भी जो कभी खरोंच से फिर से लिखे गए हैं, बहुत कम 15 साल रहते हैं।

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

ठीक है, उत्तर के लिए धन्यवाद। मेरा अंतिम प्रश्न प्रदर्शन और जावा 11 के बारे में होगा। जहां तक ​​मुझे पता है, स्प्रिंग हमेशा रनटाइम में संदर्भ उत्पन्न करता है। यह कुछ पुराने बैंकिंग कार्यक्रमों में मिनटों से लेकर कई घंटों तक का समय ले सकता है।

चलो? मुझे विश्वास नहीं है।

ईमानदारी से, मेरी अपनी आँखों से देखा जाता है।

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

हां, मुझे लगता है कि हाइबरनेट के साथ वास्तव में कुछ प्रकार का आतंक था। फिर भी, वसंत 30 सेकंड शुरू होता है, कभी-कभी एक या दो मिनट - यह अभी भी काफी लंबा समय है, क्या आपको नहीं लगता? यदि, कहते हैं, हम इसे डॉकर में चलाते हैं, तो हमें कंटेनर को तुरंत शुरू करने की आवश्यकता है। क्या स्प्रिंग स्टार्टअप समय को कम करना संभव है?

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

मैं देखता हूं। वैसे, क्या आपने GraalVM और AOT के बारे में सुना है?

हां। मैं आपको और अधिक बताऊंगा: हमारे पास स्प्रिंग फू प्रोजेक्ट है। वह प्रयोगात्मक है, मैंने उसके बारे में स्प्रिंग टिप्स श्रृंखला से एक वीडियो शूट किया। हमने इसे कोटलिन पर लिखा था, अब इसमें जावा एपीआई है। यह प्रोजेक्ट ग्रेवालम जैसे वातावरण के लिए बनाया गया था। स्प्रिंग फू गतिशील रूप से उत्पन्न परदे के पीछे या `@ कॉन्फ़िगरेशन` का उपयोग नहीं करता है। GraalVM में मूल छवि जनरेटर को यह जानने की जरूरत है कि कौन सी कक्षाएं लोड की जाएंगी। लेकिन अगर आपके पास cglib या बाइट बडी का उपयोग करके गतिशील लोडिंग है, तो यह GraalVM का उपयोग करना मुश्किल बनाता है। हाइबरनेट, स्प्रिंग और अन्य सभी लाइब्रेरी जो गतिशील रूप से उत्पन्न होने वाली प्रॉक्सी का उपयोग करते हैं, देशी छवि बनाने के लिए खराब रूप से अनुकूल हैं। इसलिए, स्प्रिंग फू में ऐसा कुछ नहीं है, यह सीधे कहा गया है। यह अभी भी स्प्रिंग का उपयोग करता है, लेकिन निर्माण अनुप्रयोगों के लिए दृष्टिकोण अलग है। और स्प्रिंग फू के फायदों में से एक यह है कि यह ग्रेवालम के साथ अच्छी तरह से काम करता है। और अब आवेदन तुरन्त शुरू होता है। मेरा मतलब है, आम तौर पर तुरन्त: एक बार यह पूरी तरह से स्मृति में है! यह याद रखना चाहिए कि GraalVM में मूल छवि जनरेटर अभी भी विकास के बहुत प्रारंभिक चरण में है। इस वजह से, कभी-कभी कठिनाइयाँ उत्पन्न होती हैं, क्योंकि यह लोगों को लगता है कि GraalVM द्वारा लॉन्च किया गया एप्लिकेशन तुरंत बहुत जल्दी लोड करना शुरू कर देगा, और रनटाइम में गति पहले की तरह ही होगी। लेकिन ऐसा नहीं होता है, क्योंकि GraalVM रनटाइम में अब आप JVM का उपयोग नहीं कर रहे हैं, सिस्टम व्यवहार भिन्न होगा। इसलिए स्वास्थ्य के लिए इस परियोजना का परीक्षण करें, लेकिन याद रखें कि यह एक मुफ्त लॉन्च त्वरण नहीं है। और फिर भी, मैं ग्रेवालम के साथ खुश हूं, उनकी टीम ने इसे फ्रेमवर्क के साथ बेहतर बनाने में बहुत प्रयास किया।

मेरा आखिरी सवाल, निश्चित रूप से, जावा 11 के बारे में होगा।

हाँ, वह सुंदर है।

इसमें स्प्रिंग के लिए क्या उपयोगी है?

स्प्रिंग डेवलपर्स के लिए, दो मुख्य मानदंड हैं जिनके द्वारा हम इस या उस तकनीक का चयन करते हैं: 1. चाहे वह व्यावसायिक आवश्यकताओं के लिए उपयुक्त हो, 2. चाहे वह हमें प्रोग्रामर के रूप में सूट करता हो। पहली कसौटी के रूप में, चाहे यह तकनीक उच्च गति, स्थिरता प्रदान करती हो, चाहे इसका दीर्घकालिक समर्थन हो। यह सब जावा 11 में मौजूद है। जावा 8 के लिए समर्थन जल्द ही समाप्त हो जाएगा, इसलिए यह लंबी अवधि के समर्थन के साथ अगले रिलीज में अपग्रेड करने के लिए समझ में आता है। वैसे, मेरे दोस्त, यदि आप अगले संस्करण में अपग्रेड करते हैं, तो OpenJDK असेंबली लें - यह हर तरह से उत्कृष्ट है। सही संस्करण प्राप्त करना बहुत आसान है, मैंने पहले ही ट्विटर पर इसके बारे में लिखा था। यह रिलीज वसंत के साथ बहुत अच्छी तरह से काम करती है - यह स्थिर है। आप कम से कम अब https://start.spring.io पर जा सकते हैं, एक नई परियोजना तैयार कर सकते हैं, जावा 11 का चयन कर सकते हैं और यह काम करेगा। IntelliJ और ग्रहण दोनों में Java 11 सपोर्ट उपलब्ध है।

दूसरी कसौटी के अनुसार, जावा 11 में स्प्रिंग डेवलपर्स के लिए कोई महत्वपूर्ण परिवर्तन नहीं हैं। यह अच्छा है कि `var` और HTTP क्लाइंट दिखाई दिए, लेकिन स्प्रिंग में पहले से ही एक प्रतिक्रियाशील WebClient था, इसलिए मुझे यकीन नहीं है कि हम HTTP क्लाइंट से लाभान्वित होंगे। जावा 10 और जावा 9 में कुछ सुविधाजनक चीजें जोड़ी गईं। इसके अलावा, जावा प्रोग्राम को स्क्रिप्ट के रूप में चलाना संभव हो गया - यह बुरा नहीं है। मुझे यकीन नहीं है कि यह वसंत के साथ ऐसा करने के लिए समझ में आता है - हालांकि दूसरी तरफ, क्यों नहीं। यह कैसा लगेगा, मुझे नहीं पता।

क्या स्प्रिंग को जावा 11 में बदलना मुश्किल था?

नहीं। वसंत के केंद्र में बहुत उच्च गुणवत्ता वाले पुस्तकालय और पारिस्थितिक तंत्र हैं। ध्यान रखें कि स्प्रिंग फ्रेमवर्क स्वयं ही क्लासपाथ और मॉड्यूलपाथ दोनों का समर्थन करता है, लेकिन मैं व्यक्तिगत रूप से मॉड्यूलपथ का उपयोग करने की अनुशंसा नहीं करता हूं। इसे सही ढंग से उपयोग करने के लिए, बाकी सब को भी मॉड्यूलपैथ का समर्थन करना चाहिए। और यह अभी तक संभव नहीं है, अब पुस्तकालयों में मॉड्यूलपथ समर्थन प्रदान करने वाले बहुत कम लोग हैं। क्लासपैथ मोड काफी अच्छा काम करता है। हमारे पास CGLib, AspectJ और JAXB XML पुस्तकालयों के साथ काफी मानक समस्याएं थीं जो सभी के पास जावा 9 पर स्विच करने के दौरान थीं। इन सभी समस्याओं का समाधान पिछले वर्ष के बारे में किया गया था, इसलिए हमारे लिए Java 11 में परिवर्तन आसान हो गया।

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

क्या यह जावा 12 में होगा?

सबसे अधिक संभावना नहीं है, वे ऐसा कुछ समय के लिए करेंगे।

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

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

हां, नहीं तो पढ़ना मुश्किल हो जाता है। आईडीई में, वे बहुत बेहतर दिखेंगे। फिर, पायथन, कोटलिन, स्काला, ग्रूवी - पिछले 20 वर्षों में किसी भी भाषा ने मल्टी-लाइन स्ट्रिंग समर्थन प्रदान किया है। मेरी राय में, यह काफी स्वाभाविक है।

शायद आप हमारे पाठकों को कुछ सलाह देना चाहेंगे? यह वसंत या धुरी की चिंता कर सकता है, और एक पूरे के रूप में जावा से संबंधित हो सकता है।

किसी भी तकनीक के साथ, वसंत का सबसे अच्छा हिस्सा इसका समुदाय है। तकनीकी रूप से, स्प्रिंग परियोजनाओं का एक अत्यंत दिलचस्प सेट है, लेकिन इसकी लंबी उम्र के लिए रहस्य एक अद्भुत समुदाय है। यदि आपको इसके लिए असहनीय लोगों के साथ संवाद करने की आवश्यकता है, तो किसी को आपके अद्भुत सॉफ़्टवेयर की आवश्यकता नहीं है। इसलिए, हम यथासंभव अनुकूल होने की कोशिश करते हैं। हमारे डेवलपर्स, जिसमें प्रोजेक्ट मैनेजर भी शामिल हैं, स्टैक ओवरफ्लो पर सवालों के जवाब देते हैं और वहां विभिन्न टैग का पालन करते हैं। हमारे पास Gitter पर चैट रूम हैं, और इसमें प्रत्येक चैट रूम GitHub पर एक रिपॉजिटरी से मेल खाता है। उदाहरण के लिए, https://gitter.im/spring-projects/spring-boot । वहां आप स्प्रिंग डेवलपर्स पा सकते हैं और उन सवालों को पूछ सकते हैं जो आपकी रुचि रखते हैं।

लोग अक्सर मुझसे पूछते हैं कि प्रोजेक्ट की मदद कैसे करें, वसंत के लिए कोड लिखना कैसे शुरू करें। हमें GitHub पर "योगदान के लिए आदर्श" जैसे टैग के साथ बहुत सारी समस्याएं हैं। हम सभी के लिए खुश हैं, लेकिन सभी परियोजनाएं सभी के अनुरूप नहीं हैं, कुछ कीड़े दूसरों की तुलना में अधिक जटिल हैं। इसलिए यदि आप हमारे साथ काम करना चाहते हैं, तो इन टैगों को देखें और समस्याओं के साथ मदद करें। इस तरह से हमारे समुदाय की पुनःपूर्ति होती है। हम सभी के काम को महत्व देते हैं जो हमारे पारिस्थितिकी तंत्र को बेहतर बनाने में मदद करता है।

विज्ञापन का मिनट। जोश लॉन्ग एक रिएक्टिव स्प्रिंग टॉक के साथ जोकर 2018 सम्मेलन में पहुंचे। सम्मेलन की आधिकारिक वेबसाइट पर टिकट खरीदे जा सकते हैं।