अज़ुल के साइमन रिटर के साथ एक साक्षात्कार में जावा का अतीत और भविष्य

हम आपको साइमन रिटर के साथ एक साक्षात्कार में पेश करते हैं, वह आदमी जिसने शुरुआत से ही जावा पर काम किया था और ज़िंग जेवीएम वर्चुअल मशीन पर काम करने वाली कंपनी अज़ुल के डिप्टी टेक्निकल डायरेक्टर और सर्वश्रेष्ठ कचरा बीनने वालों में से एक, सी 4 (कंटीन्यूअसली कॉन्ट्रैक्ट कॉम्पैक्ट कलेक्टर) के रूप में काम करता है।

• जावा के साथ एक जीवनकाल;
• जब आप सीटीओ हैं, तो प्रगति और कोड के किनारे पर कैसे रहें;
• सबसे अच्छा और सबसे खराब JDK विशेषताएं;
• जावा समुदाय प्रक्रिया कार्यकारी समिति के सदस्य;
• क्या विश्व स्तर पर कुछ तोड़ना डरावना नहीं है;
• JDK 11/12 में संक्रमण;
• OpenJDK के अपने कांटे के लिए समर्थन मूल्य;
• C4 और फाल्कन बनाम शेनान्दाह और ग्रेगल;
• क्या आपको माइक्रोसर्विस की दुनिया में एक शक्तिशाली कलेक्टर की आवश्यकता है;
• एप्लिकेशन सर्वर, जावा ईई / जकार्ता ईई और जावाएफएक्स का भाग्य;
• रूस की यात्रा और जेपोट पर एक ताजा रिपोर्ट।

किंवदंती

साइमन - साइमन रिटर, अज़ूल सिस्टम के डिप्टी सीटीओ;
यूजीन - यूजीन फिलीनियम ट्रिफोनोव , जुगोव ग्रुप के पत्रकार;
ओलेग - ओलेग ओलेगिर चिरुखिन, JUG.ru समूह के पत्रकार;

यूजीन: अज़ुल के डिप्टी सीईओ बनने से पहले क्या आप हमें अपने करियर के बारे में बता सकते हैं? विशेष रूप से, मुझे आश्चर्य है कि आप सन माइक्रोसिस्टम्स में कैसे समाप्त हुए।

साइमन: मेरा पहले से ही बहुत लंबा कैरियर है - मैंने 1987 में विश्वविद्यालय से स्नातक किया। सबसे पहले मैं यूके में एक छोटी कंपनी में यूनिक्स में शामिल हुआ था। फिर उन्होंने उस जगह पर काम किया, जहां UNIX, का आविष्कार किया गया था - बेल लैब्स में। चार साल बाद, बेल लैब्स को नोवेल ने अपने कब्जे में ले लिया, और मैं नोवेल में एक यूनिक्स सलाहकार बन गया। दो साल बाद, उनके UNIX व्यवसाय का वह हिस्सा सांताक्रूज ऑपरेशन्स द्वारा खरीदा गया था, और इस बिंदु पर मैंने फैसला किया कि मैं कुछ और करना चाहता था। इसलिए 1996 में, मैं सन माइक्रोसिस्टम्स में आ गया। ठीक दो हफ्ते बाद, फरवरी 1996 में, JDK 1.0 जारी किया गया। मैंने शुरू में सोलारिस और यूनिक्स से संबंधित चीजों पर काम किया, लेकिन जल्दी से महसूस किया कि सबसे नई और सबसे दिलचस्प चीज जावा थी। मैं एक डेवलपर और सलाहकार था, और 1999 में मैं एक आईटी प्रचारक बन गया, दूसरे शब्दों में - डेवलपर एडवोकेट, और मैं 20 वर्षों से यह कर रहा हूं। 2010 में, ओरेकल ने सन को खरीदा, और अगले 5 वर्षों में मैं इंजील टीम का नेता था। 2015 में, ओरेकल ने फैसला किया कि उसे अब डेवलपर अधिवक्ताओं की आवश्यकता नहीं है, और मुझे निकाल दिया गया। उस समय, सबसे समझदार फैसला अज़ुल में आना था, जो मैंने किया। तब से, मुझे अपने निर्णय पर पछतावा नहीं है, क्योंकि मैं वही करता हूं जो मुझे सबसे ज्यादा पसंद है - जावा के बारे में लोगों को बताना, यात्रा करना, दिलचस्प लोगों से मिलना और नई तकनीकों की कोशिश करना। यदि आप विवरण में नहीं जाते हैं, तो यह मेरा कैरियर है।

यूजीन: जो प्रभावशाली लगता है। जिन लोगों को मैं जानता हूं, आप शायद केवल एक ही हैं जिन्होंने 1.0 संस्करण के बाद से जावा के विकास में भाग लिया है। मुझे आश्चर्य है कि उसने उस समय कैसे देखा। जहां तक ​​मुझे पता है, तब इसे माइक्रोवेव और इस तरह की भाषा माना जाता था। क्या यह सच है?

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

जावा के शुरुआती संस्करणों में, पुस्तकालय बहुत सीमित थे, और परियोजना के बढ़ने के साथ सबसे महत्वपूर्ण परिवर्तनों में से एक बड़े आधार पुस्तकालयों की उपस्थिति थी। मैं अक्सर अपनी प्रस्तुतियों में इस विकास के बारे में बात करता हूं। JDK 1.0 में, डेवलपर्स के लिए 211 सार्वजनिक कक्षाएं उपलब्ध थीं, और JDK 8 से rt.jar में 4.5 हजार सार्वजनिक कक्षाएं थीं। यह जावा की लोकप्रियता के कारणों में से एक है: प्रोग्रामर को Semaphore ArrayList या Semaphore लिखने की आवश्यकता नहीं है, और JDBC के माध्यम से डेटाबेस से कनेक्ट करना आसान है।

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

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

कुछ कम महत्वपूर्ण निर्णय, यह भी, मुझे लगता है, पूरी तरह से सफल नहीं थे। हमने केवल JDK 9 में अप्रचलित एपीआई को निकालना शुरू किया - मुझे लगता है कि बहुत देर हो चुकी थी। मौजूदा कोड में कम से कम व्यवधान के साथ नियंत्रित सफाई का संचालन करना आवश्यक था। सामान्य तौर पर, कुछ चीजों को वास्तव में थोड़ा अलग किया जा सकता है। लेकिन कुल मिलाकर, जावा डेवलपर्स, निश्चित रूप से, एक महान भाषा बनाई।

यूजीन: कई आप के साथ पिछड़े संगतता और इसकी सीमाओं के बारे में सहमत हैं। जावा को कभी-कभी बहुत रूढ़िवादी माना जाता है।

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

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

ओलेग: हमारे ग्राहकों को सम्मेलनों में साक्षात्कार और भाषणों के बारे में पहले से ही बहुत कुछ पता है। लेकिन अज़ुल में अब आप जो कर रहे हैं, उसके बारे में कम ही जानते हैं। क्या आप हमें अपनी वर्तमान गतिविधियों के बारे में बता सकते हैं?

साइमन: मेरी पोस्ट का शीर्षक उप महा निदेशक है, लेकिन यह बिल्कुल सटीक रूप से वर्णन नहीं करता है कि मैं क्या कर रहा हूं। ओरेकल और सन में पहले की तरह, मैं लोगों को समझाता हूं कि मेरी कंपनी और जावा सामान्य रूप से उनकी कैसे मदद कर सकते हैं। मुझे कहना होगा कि जावा के अलावा, अज़ुल इससे ज्यादा कुछ नहीं करता। हमारे पास एक ज़ुलु OpenJDK और एक वैकल्पिक कचरा संग्रह विधि और हमारे अपने JIT संकलक के साथ एक वाणिज्यिक Zing JVM है। सामान्य तौर पर, मैं जावा के प्रसार को बढ़ावा देता हूं, हमारे संस्करण को प्राथमिकता देता हूं, और इस उद्देश्य के लिए मैं अक्सर सम्मेलनों में बोलता हूं। लेकिन अज़ुल दृष्टिकोण में, मुझे यह पसंद है कि वे सामान्य रूप से जावा को बढ़ावा देने पर बहुत ध्यान देते हैं, न कि केवल उनके उत्पाद पर। इसके लिए धन्यवाद, मैं लैम्ब्डा एक्सप्रेशन और स्ट्रीम पर पाठ्यक्रम दे सकता हूं, अपने भाषणों में जेडीके 11 की नई विशेषताओं के बारे में बात कर सकता हूं, स्थानीय प्रकार के इंजेक्शन का उपयोग कैसे करें और इसी तरह।

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

ओलेग: यह कहे बिना जाता है कि आप अपना सारा समय प्रोग्रामिंग में नहीं लगा सकते। आप विकास की दुनिया के संपर्क में कैसे रहते हैं? क्या आप बिल्कुल भी लिखते हैं, क्या आप तकनीकी लेख पढ़ते हैं?

साइमन: बेशक, और मेरे लिए नवीनतम परिवर्तनों पर अपडेट रहना बहुत महत्वपूर्ण है। तथ्य यह है कि अज़ुल जेसीपी का एक सदस्य है जो मुझे बहुत मदद करता है, और मैं कार्यकारी समिति में अज़ुल का प्रतिनिधित्व करता हूं। वहां मैं अन्य प्रतिनिधियों के साथ संवाद करता हूं और देखता हूं कि जावा किस दिशा में विकास कर रहा है। इसके अलावा, मैं JSRs पर जावा एसई विशेषज्ञ समूह का हिस्सा हूं। इससे चल रहे परिवर्तनों को समझने में भी मदद मिलती है। इसके बाद, Azul सक्रिय रूप से OpenJDK में शामिल है, जो मुझे अतिरिक्त दृश्यता देता है। इसके अलावा, मैं तकनीकी लेख पढ़ता हूं और ओरेकल के परिचितों के साथ बहुत सारी बातें करता हूं, जिससे मुझे यह पता चलता है कि कंपनी में क्या हो रहा है।

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

ओलेग: आइए कल्पना करें कि आपके पास एक महाशक्ति है, जिसकी बदौलत आप जावा से एक फीचर को हटा सकते हैं और किसी अन्य को जोड़ सकते हैं। आप क्या चुनेंगे?

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

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

ओलेग: आपने जेसीपी कार्यकारी समिति का उल्लेख किया। वास्तव में इसकी गतिविधि कैसे आगे बढ़ती है? क्या आपके पास अपनी बैठक की इमारत है, एक असली सरकार की तरह "व्हाइट हाउस"?

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

ओलेग: और आप, विशेषज्ञ समूह के सदस्य के रूप में, नई सुविधाओं को जोड़ने से डरते नहीं हैं? आखिरकार, जावा एक बहुत ही जटिल प्रणाली है, आप गलती से सब कुछ तोड़ सकते हैं।

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

साइमन और मैं एक साल पहले JBreak Java सम्मेलनों में घूमते हैं

ओलेग: क्या आप और आपकी कंपनी पहले ही जावा 11 या 12 पर स्विच कर चुके हैं?

साइमन: मेरी परियोजनाओं में मैं अक्सर जावा 11 का उपयोग करता हूं, लेकिन यह कोड आमतौर पर उत्पादन के लिए नहीं है, बल्कि यह प्रयोगात्मक है। दुनिया भर के डेवलपर्स के साथ मेरी बातचीत से, मुझे यह धारणा मिलती है कि लोग धीरे-धीरे जेडीके 11 में जा रहे हैं, क्योंकि यह दीर्घकालिक समर्थन के साथ रिलीज है। बेशक, हमें यह ध्यान रखना चाहिए कि यह समर्थन अब पहले की तुलना में विभिन्न स्थितियों पर प्रदान किया गया है। व्यावसायिक उपयोग के लिए अब आपको भुगतान करना होगा। ऐसी कंपनियां हैं जो Oracle के समान रिलीज़ शेड्यूल का पालन करती हैं। यह अज़ुल, AdoptOpenJDK, Amazon Coretto है। वे उम्मीद करते हैं कि JDK 11 को दीर्घकालिक समर्थन प्राप्त होगा, और JDK 17 को अगली दीर्घकालिक रिलीज के रूप में देखा जाएगा। एक नियम के रूप में, लोग हर छह महीने में एक नए संस्करण में अपग्रेड करने के लिए तैयार नहीं हैं, खासकर उत्पादन में। स्टार्टअप ऐसा करने में सक्षम हो सकते हैं, लेकिन अधिकांश वाणिज्यिक उपयोगकर्ताओं को स्थिरता की आवश्यकता होती है। कम से कम अब तो है।

ओलेग: वैसे, जहां तक ​​मुझे पता है, AdoptOpenJDK TCK परीक्षणों का उपयोग नहीं करते हैं । चूंकि परीक्षण अभी भी आवश्यक है, वे अन्य दृष्टिकोणों की पेशकश करते हैं, जिनके बारे में उन्होंने पिछले FOSDEM सम्मेलन में बात की, मशीन सीखने की तरह अलग-अलग पागल सामान। इन तरीकों में मशीन सीखने जैसी मौलिक चीजें थीं। क्या आपके पास OpenJDK के अपने कांटे को बनाए रखने में बहुत प्रयास हैं?

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

ओलेग: अज़ुल का अपना OpenJDK वितरण, ज़ुलु है। क्या आप उसके बारे में बता सकते हैं? क्या यह खुला स्रोत है? उसके और बाकी सभी के बीच क्या अंतर है?

साइमन: ज़ुलु के दो संस्करण हैं - कम्युनिटी एडिशन और एंटरप्राइज एडिशन। द्वारा और बड़े, यह Red Hat के समान ही है। सामुदायिक संस्करण एक खुला संस्करण है, इसे हमारी वेबसाइट से डाउनलोड किया जा सकता है। इसे GPLv2 के तहत Classpath अपवाद के साथ लाइसेंस दिया गया है, अर्थात OpenJDK के समान ही, इसलिए आप कृपया इसका उपयोग कर सकते हैं। लेकिन इस संस्करण में वाणिज्यिक समर्थन नहीं है। ज़ुलु एंटरप्राइज संस्करण उन बड़े संगठनों पर लक्षित है जिन्हें उत्पाद समर्थन की आवश्यकता है। अपडेट कैसे होता है, इन संस्करणों में अंतर होता है। एंटरप्राइज एडिशन के लिए, हम खुद को बैकपोर्ट करते हैं। जब ओरेकल जेडडीके के अगले संस्करण के लिए एक अपडेट जारी करता है, तो 12 या 13 कहते हैं, हम बहुत जल्दी इसे 8, 7 और यहां तक ​​कि ज़ुलु एंटरप्राइज के 6 संस्करणों के लिए उपलब्ध कराते हैं। सामुदायिक संस्करण में, हम बस OpenJDK स्रोत कोड लेते हैं और इसे संकलित करते हैं। यदि फ़िक्सेस पहले से ही इस कोड में हैं, तो वे कम्युनिटी एडिशन में होंगे, लेकिन अगर किसी और ने बैक-अप नहीं लिया, तो वे कम्युनिटी एडिशन में भी नहीं होंगे। मेरी राय में, यह एक ध्वनि दृष्टिकोण है।

ओलेग: हाल ही में, कई कंपनियों को अज़ुल क्या करता है के करीब उत्पाद मिले हैं। उदाहरण के लिए, अब कई लो-पिट कचरा संग्रहकर्ता हैं, और ग्रेग जेआईटी कंपाइलर, अज़ुल के फाल्कन के समान, ओरेकल लैब्स में बनाया गया था। क्या आप हमें बता सकते हैं कि वास्तव में C4 और फाल्कन क्या हैं, और अन्य कंपनियों के समान उत्पादों से उनका अंतर क्या है?

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

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

जेआईटी संकलक के लिए, हम उस कोड को सुधारना चाहते थे जो उन्होंने उत्पन्न किया था, और शुरू में सी 2 संकलक पर ध्यान केंद्रित किया। लेकिन सी 2 पहले से ही 20 साल से अधिक पुराना है, और यह काफी कठिन लिखा जाता है, इसे संशोधित करना मुश्किल होगा। हमने LLVM को भी देखा, जो एक ओपन सोर्स प्रोजेक्ट है जो कंपाइलर्स के साथ काम करता है। हमने उनका स्रोत कोड लिया और इसे JVM में एकीकृत कर दिया। LLVM मुख्य रूप से स्थैतिक AOT संकलन करता है, हमने JIT संकलन के लिए इस तकनीक का उपयोग किया है। चूंकि हम खुले स्रोत समुदाय के सम्मानित सदस्य हैं, इसलिए हमने इन परिवर्तनों को LLVM परियोजना में जोड़ा है। हमारे पास एक बहुत ही सुंदर मॉड्यूलर संरचना है, जिसके लिए नई सुविधाओं को जोड़ना आसान है, ताकि आप नए आंतरिक, नए मॉड्यूल आदि जोड़ सकें। इसके अलावा, इंटेल, सोनी, माइक्रोसॉफ्ट के लोग एलएलवीएम पर काम कर रहे हैं, जो निश्चित रूप से हमें बहुत मदद करता है। हर बार जब हम अपना सोर्स कोड अपडेट करते हैं, तो हमें दूसरे लोगों द्वारा किए गए प्रदर्शन में सुधार होता है।

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

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

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

, , . , . , . , , , . , . , , . , .

, , , , , Golang. JDK 11 Epsilon, . : , , , — ? , , , . , . , — , .

: , ? GlassFish Eclipse. , ?

: , . , , . , , , . , . Kubernetes — , . .

: Eclipse Jakarta EE , — , .. Docker, Kubernetes .. Java ? ? Falcon Arm64?

: , Falcon , . - , LLVM , ARM. , . , .

: , Java Enterprise JavaFX OpenJDK. , ? , , Java EE JavaFX?

: C JavaFX , . , JavaFX 2004 . UI. JavaFX, . , Swing AWT, style sheets, layouts . , JavaFX Java SE, . Oracle , , . , JDK, . JavaFX, , , Gluon. Azul JavaFX Zulu. , .

Java EE, , , JDK 11 java.se.ee — , . JAX-B CORBA, , . JAX-WS . , -, , JDK. . . Maven Central. , Oracle Java. , , , . Java 24 , , . OpenJDK, , . , , .

: , JPoint, , ? ?

: , JPoint. JBreak , . , . , , .

. , . , , 10 , . . , 10 , , - . , , , , , - . , .

, . , , . .

: ?

: , Java , . 9 12, . — Valhalla value types reified generics, Loom fibers. Loom . . Amber, Java . , .

, . , , , LTS . , , - . , . , , , .

JPoint 2019: «JDK 12: Pitfalls for the unwary» «Local variable type inference: Friend or foe?» । , . GraalVM (Thomas Wuerthinger ), Liberica JDK ( ), Excelsior JET ( ), .. JPoint 2019 5-6 , .