👨🏻‍🍳 🤖 🤖 जावा REPL आप ScriptEngine नहीं है 👨🏻‍🏫 👇🏽 💒

नमस्कार, हेब्र! मेरा नाम दीमा है, मैं hh.ru पर "आर्किटेक्चर" टीम में एक डेवलपर हूं। अन्य बातों के अलावा, मैं सहयोगियों के लिए चीजों को आसान बनाता हूं। उत्पादन में कोड चलाना एक विशिष्ट कार्य है। इसलिए, जब मैंने सुना कि इसके साथ समस्याएं हैं, तो मैंने उन्हें ठीक करने का फैसला किया।

हमेशा डेटा परिवर्तन को सरल UPDATE / INSERT नहीं बनाया जा सकता है - कभी-कभी आपको सत्यापन, ईवेंट बसों और बहुत कुछ का उपयोग करने की आवश्यकता होती है। ऐसे मामलों में, सबसे इष्टतम समाधान सीधे आवेदन में मनमाना कोड निष्पादित करना है। हमारे पास जावा है, इसलिए जब JEP-222 दिखाई दिया , तो मैंने तुरंत सोचा कि JShell स्क्रिप्टिंग को फिर से सुविधाजनक बनाने में सक्षम हो सकता है। एक चमत्कार नहीं हुआ, और इसलिए कटौती के तहत आपको उदाहरणों के साथ jvm के लिए सबसे प्रसिद्ध जावा दुभाषियों (और "निकट-जावा") की बहुत गहरी तुलना नहीं मिलेगी। मैं बिल्ली के नीचे रुचि रखने वाले सभी को आमंत्रित करता हूं।

हम स्क्रिप्ट चलाने के लिए बीनशेल का उपयोग करते हैं, और 2019 के लिए यह भयानक है: 2016 से अंतिम रिलीज, लंबोदा और यहां तक कि जेनरिक के लिए समर्थन की कमी - यह सब हमें कोड लिखने के लिए मजबूर करता है जो कि जावा 1.4 के बाद से किसी ने नहीं लिखा है।

मापदंड

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

वर्तमान जावा सिंटैक्स के लिए समर्थन;
दुभाषिया के लिए एक बाहरी संदर्भ पारित करने की क्षमता;
निष्पादन को बाधित करने की क्षमता;
I / O को पुनर्निर्देशित करने की क्षमता;
सूचनात्मक प्रतिक्रिया।

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

तो चलिए चलते हैं

JShell

वर्तमान जावा सिंटैक्स के लिए समर्थन - हाँ
संदर्भ देने की क्षमता - नहीं
निष्पादन को बाधित करने की क्षमता - हाँ
I / O को पुनर्निर्देशित करने की क्षमता - नहीं
सूचनात्मक प्रतिक्रिया - हाँ

मुझे तुरंत यह कहना होगा कि JEP-222 एक एम्बेडेड दुभाषिया बनाने का लक्ष्य नहीं रखता है - इसका लक्ष्य REPL है , अर्थात्, जल्दी से प्रोटोटाइप कोड की क्षमता है। यह कई परिणामों से भरा है।

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

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

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

अद्यतन: JShell से स्क्रिप्टेड स्क्रिप्ट प्राप्त किया । लेकिन इसके लिए मुझे अपना लॉन्च मोड लिखना होगा

BeanShell

वर्तमान जावा सिंटैक्स के लिए समर्थन - नहीं
संदर्भ देने की क्षमता - हाँ
निष्पादन को बाधित करने की क्षमता - हाँ
I / O को पुनर्निर्देशित करने की क्षमता - हाँ (लेकिन विशेष विधियों के उपयोग की आवश्यकता होती है)
सूचनात्मक प्रतिक्रिया - हाँ

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

इस लेखन के समय, बिटशेल ने वास्तव में जेनरिक का समर्थन किया था, लेकिन लैम्ब्डा अभी भी काम नहीं करता है। शायद स्थिति की रिहाई से स्थिति बदल जाएगी।
लेकिन एकीकरण के संदर्भ में, इंजन काफी अनुकूल है - मानक javax.scripting के लिए समर्थन, रनटाइम त्रुटियाँ पर्याप्त हैं:

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

Kotlin

वर्तमान जावा सिंटैक्स के लिए समर्थन - नहीं
संदर्भ देने की क्षमता - नहीं
निष्पादन को बाधित करने की क्षमता - हाँ
I / O को पुनर्निर्देशित करने की क्षमता - नहीं
सूचनात्मक प्रतिक्रिया - हाँ

बहुत कोड के साथ जावा कोड, मान्य कोटलिन कोड होगा। लेकिन मैं कोटलिन में जावा पर कम से कम किसी भी तरह से कुछ भी लॉन्च करने में सफल नहीं हुआ, लेकिन फिर भी चलो कोशिश करते हैं।
कोटलिन ने पहले ही कुछ वर्षों के लिए javax.scripting समर्थन की घोषणा की है।

पहली समस्या जो हमें निपटानी है, वह निर्भरता-नरक है।
कोटलिन-कंपाइलर में org.jdom क्लासेस शामिल होती हैं, जिन्होंने एप्लीकेशन में org.jdom से लड़ना शुरू कर दिया और इसे लपेट दिया ... इसलिए, हमारे पास kotlin-compiler-embeddable है, जहाँ इन सभी वर्गों को कस्टम पैकेज में रखा गया है।

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

त्रुटियां भी काफी हैं:

ग्रूवी

वर्तमान जावा सिंटैक्स के लिए समर्थन - नहीं, लेकिन एनालॉग हैं
संदर्भ देने की क्षमता - हाँ
निष्पादन को बाधित करने की क्षमता - हाँ
I / O को पुनर्निर्देशित करने की क्षमता - हाँ
सूचनात्मक प्रतिक्रिया - हाँ

Grooves, javax.scripting का समर्थन करने के अलावा, दुभाषिया एकीकरण के लिए अपने स्वयं के, अधिक उन्नत एपीआई प्रदान करता है। उदाहरण के लिए, एएसटी परिवर्तन को पारित करना संभव है, जो आपको प्रत्येक अभिव्यक्ति के बाद सशर्त रुकावट जोड़ने की अनुमति देता है। यह बात इतनी शक्तिशाली है कि यह पहले से ही डरावना है ।

इसके अलावा, जावा (और विशेष रूप से बिटशेल) कोड काफी मान्य नाली कोड हो सकता है।
एकीकरण और परीक्षण ऑपरेशन सफल था, शीट इनिशियलाइज़ेशन और लैम्ब्डा सिंटैक्स के अपवाद के साथ (उन्हें घुंघराले ब्रेसिज़ में लपेटना पड़ता है), मौजूदा बिनशेल स्क्रिप्ट ने समस्याओं के बिना काम किया। त्रुटियाँ क्रिया से अधिक हैं:

शायद आज यह एकमात्र दुभाषिया है, जो एक तरफ, आपको 2019 में नमूने के लिए कोड लिखने की अनुमति देता है, और दूसरी तरफ, यह सभी आवश्यकताओं को पूरा करता है जो दुभाषिया को प्रस्तुत करना उचित है।

हम क्या निष्कर्ष निकाल सकते हैं?

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

दूसरा - आज जावा में स्क्रिप्ट निष्पादित करने के लिए एक भी उपकरण नहीं है, इसलिए यदि आपको इस तरह के उपकरण की आवश्यकता है, तो एक नया वाक्यविन्यास सीखने के लिए तैयार रहें।