2020 के लिए इंटेलीज प्लेटफार्म टीम प्लान्स

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

उत्पादकता

अनुक्रमण की गति

इस समय इंडेक्सिंग हमारे IDE के प्रदर्शन के साथ सबसे समस्याग्रस्त स्थानों में से एक है। हमने कई दिशाओं से इसके समाधान के लिए संपर्क किया है।

सबसे पहले, हम तैयार-निर्मित सूचकांक टुकड़ों का समर्थन करने की योजना बनाते हैं । अब, प्रत्येक IntelliJ IDEA कॉपी के बजाय java.lang.String वर्ग को फिर से अनुक्रमणित करते हुए, हम डाउनलोड के लिए JDK के लिए एक तैयार-किए गए अनुक्रमणिका अंश प्रदान कर सकते हैं, जिसे अतिरिक्त CPU लागतों के बिना पुन: उपयोग किया जा सकता है। जेडीके के अलावा, हम मावेन सेंट्रल से पुस्तकालयों के लिए तैयार किए गए सूचकांक टुकड़े प्रदान करने की संभावना तलाश रहे हैं, साथ ही साथ अन्य आईडीई में दुभाषियों और पैकेजों के लिए भी। हम टीमों और संगठनों को अपनी परियोजनाओं के कोड के लिए रेडी-मेड इंडेक्स अंशों का उपयोग करने की अनुमति देना चाहते हैं, लेकिन हमारे पास अभी तक इसके लिए ठोस योजना नहीं है।


दूसरे, हम अनुक्रमण के दौरान उपलब्ध कार्यों की एक विस्तृत श्रृंखला बनाकर अनुक्रमणिका को काम में कम बाधा डालने की योजना बनाते हैं।

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

और अंत में, हम अच्छे पुराने अनुकूलन से निपटना जारी रखते हैं - यह सुनिश्चित करने के लिए कि अनुक्रमणिका को अनावश्यक डेटा नहीं मिलता है, और अनुक्रमण प्रक्रिया न्यूनतम संभव संसाधनों का उपयोग करती है।

आईडीई डेटा संरचनाओं के लिए नए बहु-थ्रेडेड एक्सेस

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

IntelliJ IDEA के भोर में, एक आर्किटेक्चरल निर्णय लिया गया था जिसमें UI स्ट्रीम से IDE डेटा संरचनाओं के सभी संशोधनों का प्रदर्शन किया जाना आवश्यक था। इसमें दोनों बुनियादी क्रियाएं (एक दस्तावेज़ में एक चरित्र को सम्मिलित करना) और लंबा संचालन (कई स्थानों से बुलाया विधि का नाम बदलना) शामिल हैं। यह वास्तुकला प्रोग्रामिंग मॉडल को बहुत सरल करता है, लेकिन स्पष्ट रूप से इंटरफ़ेस की जवाबदेही को कम करता है।

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

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

डाउनलोड करें और पुनः आरंभ करने के बिना प्लगइन्स अनलोड करें

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

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

विकास स्क्रिप्ट समर्थन

सहयोगात्मक संपादन

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

पतली ग्राहकों के पास IDE की बुनियादी कार्यक्षमता तक पहुंच होगी, जैसे कि नेविगेशन, ऑटो-पूर्ण और डीबगिंग, लेकिन उपलब्ध कार्यों का 100% समर्थन नहीं करेगा। (उदाहरण के लिए, संस्करण नियंत्रण प्रणालियों के साथ काम करना प्रारंभिक रिलीज के लिए वर्तमान योजना में शामिल नहीं है।) समर्थित कार्यों का सटीक सेट वर्तमान में परिभाषित नहीं किया गया है, और हम समर्थित और कब होंगे, इस बारे में सवालों के जवाब देने के लिए तैयार नहीं हैं।

सह-संपादन के लिए समर्थन राइडर प्रोटोकॉल पर आधारित है, इसलिए सबसे अधिक संभावना है कि यह शुरू में इस उत्पाद में दिखाई देगा और फिर अन्य आईडीई में फैल जाएगा। किसी भी स्थिति में, इसमें से कोई भी IntelliJ IDEA 2020.1 रिलीज में दिखाई नहीं देगा - यह लंबी अवधि के लिए एक योजना है।

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

पतले ग्राहक का दृष्टिकोण अन्य परिदृश्यों के लिए उपयोगी हो सकता है, जैसे कि IDE बैकएंड को क्लाउड में ले जाना, लेकिन हम इस क्षेत्र में किसी भी योजना की घोषणा करने के लिए तैयार नहीं हैं।

क्लाउड लॉन्च समर्थन

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

अब हम प्लेटफ़ॉर्म स्तर पर "निष्पादन के लिए पर्यावरण" की अवधारणा को जोड़ रहे हैं, जो फ़ाइलों को या उससे कॉपी करने का एक तरीका प्रदान करता है, साथ ही इसमें प्रक्रियाएं भी शुरू करता है। IntelliJ IDEA 2020.1 में, हम डॉकर कंटेनर में और एक ssh कनेक्शन के माध्यम से स्थानीय मशीन पर निष्पादन का समर्थन करते हैं। आप जावा और गो के लिए लॉन्च कॉन्फ़िगरेशन में चलाने के लिए पर्यावरण का चयन कर सकते हैं।

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

नई डिजाइन मॉडल डिजाइन

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

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

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

सारांश

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

हम आप से सुनने के लिए उत्सुक हैं। इसके अलावा, हम आपको हमारे आरंभिक प्रवेश कार्यक्रम में भाग लेने के लिए आमंत्रित करते हैं, जो आपको आधिकारिक रिलीज़ में आने से पहले इनमें से कुछ विशेषताओं को आज़माने का अवसर देगा।