1C को लागि टेक्नोलोजी प्लेटफर्मको रूपमा ग्रहण: उद्यम विकास उपकरणहरू

हुनसक्छ, ग्रहण लामो समय देखि कुनै विशेष परिचय आवश्यक छैन। धेरै मानिसहरू Eclipse सँग परिचित छन् Eclipse Java विकास उपकरणहरू (JDT)। यो यो लोकप्रिय खुला स्रोत Java IDE हो जुन धेरै विकासकर्ताहरूले "Eclipse" शब्दसँग सम्बद्ध छन्। यद्यपि, Eclipse दुबै विकास उपकरणहरू (Eclipse Platform), र JDT सहित यसको आधारमा निर्मित धेरै IDEs एकीकृत गर्नको लागि एक्स्टेन्सिबल प्लेटफर्म हो। Eclipse दुबै Eclipse Project हो, Eclipse Platform र JDT को विकासको समन्वय गर्ने उच्च-स्तरीय परियोजना, र Eclipse SDK, त्यो विकासको डेलिभर गरिएको परिणाम। अन्तमा, Eclipse परियोजनाहरूको विशाल समुदायको साथ खुला स्रोत फाउन्डेशन हो, ती सबै जाभामा लेखिएका वा विकास उपकरणहरूसँग सम्बन्धित छैनन् (उदाहरणका लागि, परियोजनाहरू ग्रहण IoT и ग्रहण विज्ञान)। ग्रहणको संसार धेरै विविध छ।

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

ग्रहण वास्तुकला को परिचय

उदाहरण प्रयोग गरेर पहिले ग्रहण वास्तुकलाका केही सामान्य पक्षहरू हेरौं Eclipse Java विकास उपकरणहरू (JDT)। उदाहरणको रूपमा JDT को छनौट आकस्मिक होइन। यो Eclipse मा देखिने पहिलो एकीकृत विकास वातावरण हो। अन्य *DT Eclipse परियोजनाहरू, जस्तै Eclipse C/C++ विकास उपकरण (CDT), पछि सिर्जना गरियो र JDT बाट आधारभूत वास्तु सिद्धान्तहरू र व्यक्तिगत स्रोत कोड टुक्राहरू उधारो लिनुहोस्। JDT मा राखिएको वास्तुकलाको आधारभूत कुराहरू 1C: उद्यम विकास उपकरणहरू सहित Eclipse प्लेटफर्मको शीर्षमा बनाइएको लगभग कुनै पनि IDE को लागि आजको लागि सान्दर्भिक छन्।

सबै भन्दा पहिले, यो ध्यान दिनु पर्छ कि Eclipse एक स्पष्ट वास्तुकला लेयरिंग द्वारा विशेषता हो, विशिष्ट प्रोग्रामिङ भाषाहरु लाई समर्थन गर्न डिजाइन गरिएको कार्यक्षमता देखि भाषा-स्वतन्त्र कार्यक्षमता को पृथक्करण संग, र सम्बन्धित घटकहरु बाट UI-स्वतन्त्र "कोर" कम्पोनेन्ट को अलगाव संग। समर्थन प्रयोगकर्ता इन्टरफेस संग।

यसरी, ग्रहण प्लेटफर्मले एक साझा, भाषा-स्वतन्त्र पूर्वाधार परिभाषित गर्दछ, र जाभा विकास उपकरणहरूले ग्रहणमा पूर्ण-विशेषतायुक्त Java IDE थप्छन्। दुबै ग्रहण प्लेटफर्म र JDT धेरै कम्पोनेन्टहरू मिलेर बनेका छन्, जसमध्ये प्रत्येक UI-स्वतन्त्र "कोर" वा UI तह (चित्र 1) सँग सम्बन्धित छ।

चामल। 1. ग्रहण प्लेटफर्म र JDT

ग्रहण प्लेटफर्मको मुख्य कम्पोनेन्टहरू सूचीबद्ध गरौं:

• रनटाइम - प्लगइन पूर्वाधार परिभाषित गर्दछ। ग्रहण एक मोड्युलर वास्तुकला द्वारा विशेषता हो। अनिवार्य रूपमा, ग्रहण "विस्तार बिन्दुहरू" र "विस्तारहरू" को संग्रह हो।
• कार्यक्षेत्र - एक वा बढी परियोजनाहरू प्रबन्ध गर्दछ। एउटा परियोजनामा ​​फोल्डरहरू र फाइलहरू हुन्छन् जुन सीधै फाइल प्रणालीमा म्याप गरिएका हुन्छन्।
• मानक विजेट टूलकिट (SWT) - अपरेटिङ सिस्टमसँग एकीकृत आधारभूत प्रयोगकर्ता इन्टरफेस तत्वहरू प्रदान गर्दछ।
• JFace - SWT को शीर्षमा निर्मित धेरै UI फ्रेमवर्कहरू प्रदान गर्दछ।
• कार्यशाला - Eclipse UI प्रतिमान परिभाषित गर्दछ: सम्पादकहरू, दृश्यहरू, परिप्रेक्ष्यहरू।

यो भनिन्छ कि ग्रहण प्लेटफर्मले डिबग, तुलना, खोज, र टोली सहित एकीकृत विकास उपकरणहरू निर्माण गर्नका लागि धेरै अन्य उपयोगी घटकहरू पनि प्रदान गर्दछ। JFace Text को विशेष उल्लेख गर्नुपर्छ - स्रोत कोडको "स्मार्ट सम्पादकहरू" निर्माण गर्ने आधार। दुर्भाग्यवश, यी कम्पोनेन्टहरूका साथै UI लेयर कम्पोनेन्टहरूको पनि सरसरी परीक्षा यस लेखको दायरा भित्र सम्भव छैन, त्यसैले यस खण्डको बाँकी भागमा हामी आफैलाई मुख्य "मूल" कम्पोनेन्टहरूको सिंहावलोकनमा सीमित गर्नेछौं। ग्रहण प्लेटफर्म र JDT।

कोर रनटाइम

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

कोर कार्यक्षेत्र

Eclipse प्लेटफर्मको शीर्षमा निर्मित लगभग कुनै पनि एकीकृत विकास वातावरण ग्रहण कार्यस्थानसँग काम गर्दछ। यो कार्यस्थान हो जुन सामान्यतया IDE मा विकसित अनुप्रयोगको स्रोत कोड समावेश गर्दछ। कार्यस्थान नक्सा सिधै फाइल प्रणालीमा र परियोजनाहरू समावेश गर्दछ, जसमा फोल्डरहरू र फाइलहरू छन्। यी परियोजनाहरू, फोल्डरहरू, र फाइलहरू भनिन्छ स्रोतहरू कार्यक्षेत्र। Eclipse मा कार्यस्थान कार्यान्वयनले फाइल प्रणालीको सम्बन्धमा क्यासको रूपमा कार्य गर्दछ, जसले संसाधन रूखको ट्र्याभर्सललाई महत्त्वपूर्ण रूपमा गति दिन सम्भव बनाउँछ। थप रूपमा, कार्यस्थान सहित धेरै अतिरिक्त सेवाहरू प्रदान गर्दछ स्रोत परिवर्तनको लागि सूचना संयन्त्र и वृद्धिशील निर्माण पूर्वाधार.

कोर रिसोर्स कम्पोनेन्ट (org.eclipse.core.resources प्लगइन) कार्यस्थान र यसका स्रोतहरूलाई समर्थन गर्न जिम्मेवार छ। विशेष गरी, यो कम्पोनेन्टले फारममा कार्यस्थानमा प्रोग्रामेटिक पहुँच प्रदान गर्दछ स्रोत मोडेलहरू। यस मोडेलसँग प्रभावकारी रूपमा काम गर्न, ग्राहकहरूलाई स्रोतमा लिङ्क प्रस्तुत गर्न सरल तरिका चाहिन्छ। यस अवस्थामा, यो वस्तु लुकाउन वांछनीय हुनेछ जुन सीधा ग्राहक पहुँचबाट मोडेलमा स्रोतको स्थिति भण्डारण गर्दछ। अन्यथा, उदाहरणका लागि, फाइल मेटाउने अवस्थामा, ग्राहकले अब मोडेलमा नभएको वस्तुलाई समात्न जारी राख्न सक्छ, आगामी समस्याहरूको साथ। Eclipse भनिने केहि प्रयोग गरेर यो समस्या समाधान गर्दछ ह्यान्डल गर्नुहोस् स्रोत। ह्यान्डलले कुञ्जीको रूपमा कार्य गर्दछ (यसले कार्यस्थानमा स्रोतको बाटो मात्र थाहा छ) र आन्तरिक मोडेल वस्तुमा पहुँचलाई पूर्ण रूपमा नियन्त्रण गर्दछ, जसले स्रोतको अवस्थाको बारेमा जानकारी भण्डारण गर्दछ। यो डिजाइन ढाँचा को एक भिन्नता हो ह्यान्डल/शरीर.

चामल। चित्र २ ले स्रोत मोडेलमा लागू गरिएको ह्यान्डल/बॉडी मुहावरालाई चित्रण गर्दछ। IRResource इन्टरफेसले स्रोतको ह्यान्डललाई प्रतिनिधित्व गर्दछ र एक API हो, यो इन्टरफेस लागू गर्ने संसाधन वर्गको विपरीत, र ResourceInfo वर्ग, जसले शरीरलाई प्रतिनिधित्व गर्दछ, जुन API हरू होइनन्। हामी जोड दिन्छौं कि ह्यान्डलले कार्यस्थान रूटको सापेक्ष संसाधनको मार्ग मात्र थाहा छ र स्रोत जानकारीको लिङ्क समावेश गर्दैन। स्रोत जानकारी वस्तुहरूले तथाकथित "तत्व रूख" बनाउँछ। यो डेटा संरचना मेमोरीमा पूर्ण रूपमा भौतिक बनाइएको छ। ह्यान्डलसँग सम्बन्धित स्रोत जानकारी उदाहरण फेला पार्न, तत्व रूख त्यो ह्यान्डलमा भण्डारण गरिएको पथ अनुसार पार गरिन्छ।

चामल। 2. IRsource र ResourceInfo

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

• ह्यान्डल एक मूल्य वस्तु हो। मूल्य वस्तुहरू अपरिवर्तनीय वस्तुहरू हुन् जसको समानता पहिचानमा आधारित हुँदैन। त्यस्ता वस्तुहरू सुरक्षित रूपमा ह्याश गरिएका कन्टेनरहरूमा कुञ्जीको रूपमा प्रयोग गर्न सकिन्छ। ह्यान्डलका धेरै उदाहरणहरूले एउटै स्रोतलाई सन्दर्भ गर्न सक्छ। तिनीहरूलाई तुलना गर्न, तपाईंले बराबर (वस्तु) विधि प्रयोग गर्न आवश्यक छ।
• ह्यान्डलले स्रोतको व्यवहारलाई परिभाषित गर्दछ, तर स्रोतको अवस्थाको बारेमा जानकारी समावेश गर्दैन (यसले भण्डारण गर्ने डेटा मात्र "कुञ्जी", स्रोतको बाटो हो)।
• ह्यान्डलले अवस्थित नभएको स्रोतलाई जनाउन सक्छ (कि त अहिलेसम्म सिर्जना गरिएको छैन, वा पहिले नै मेटाइएको स्रोत)। IResource.exists() विधि प्रयोग गरेर स्रोतको अस्तित्व जाँच गर्न सकिन्छ।
• केही अपरेशनहरू ह्यान्डलमा भण्डारण गरिएको जानकारीको आधारमा मात्र लागू गर्न सकिन्छ (तथाकथित ह्यान्डल-मात्र सञ्चालनहरू)। उदाहरणहरू हुन् IResource.getParent(), getFullPath(), आदि। यस्तो अपरेशन सफल हुनको लागि स्रोत अवस्थित हुनु आवश्यक छैन। सञ्चालनहरू जसलाई सफल हुनको लागि स्रोत अवस्थित हुन आवश्यक छ भने स्रोत अवस्थित छैन भने CoreException फाल्नुहोस्।

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

चामल। 3. IResourceChangeEvent र IResourceDelta

स्रोत डेल्टामा आधारित अधिसूचना संयन्त्रमा निम्न विशेषताहरू छन्:

• एकल परिवर्तन र धेरै परिवर्तनहरू एउटै संरचना प्रयोग गरी वर्णन गरिएको छ, किनकि डेल्टा पुनरावर्ती संरचनाको सिद्धान्त प्रयोग गरेर बनाइएको हो। ग्राहक ग्राहकहरूले डेल्टाको रूख मार्फत पुनरावर्ती वंश प्रयोग गरेर स्रोत परिवर्तन सूचनाहरू प्रशोधन गर्न सक्छन्।
• डेल्टामा यसको चाल र/वा यससँग सम्बन्धित "मार्करहरू" मा परिवर्तनहरू (उदाहरणका लागि, सङ्कलन त्रुटिहरू मार्करहरूको रूपमा प्रतिनिधित्व गरिन्छ) सहित, स्रोतमा भएका परिवर्तनहरूको बारेमा पूर्ण जानकारी समावेश गर्दछ।
• स्रोत सन्दर्भहरू ह्यान्डल मार्फत बनाइएको हुनाले, डेल्टाले स्वाभाविक रूपमा टाढाको स्रोतलाई सन्दर्भ गर्न सक्छ।

हामी चाँडै हेर्नेछौं, संसाधन मोडेल परिवर्तन सूचना संयन्त्रको डिजाइनको मुख्य भागहरू अन्य ह्यान्डल-आधारित मोडेलहरूको लागि पनि सान्दर्भिक छन्।

JDT कोर

Eclipse कार्यस्थान संसाधन मोडेल एक मौलिक भाषा-अज्ञेयवादी मोडेल हो। JDT कोर कम्पोनेन्ट (प्लगइन org.eclipse.jdt.core) ले जाभा परिप्रेक्ष्यबाट कार्यस्थान संरचनालाई नेभिगेट गर्न र विश्लेषण गर्नको लागि API प्रदान गर्दछ, तथाकथित "जाभा मोडेल" (जाभा मोडेल)। यस API लाई जाभा तत्वहरूको सर्तमा परिभाषित गरिएको छ, अन्तर्निहित स्रोत मोडेल API को विपरीत, जुन फोल्डरहरू र फाइलहरूको सर्तमा परिभाषित गरिएको छ। जाभा तत्व रूख को मुख्य इन्टरफेस चित्र मा देखाइएको छ। ४।

चामल। 4. जाभा मोडेल तत्वहरू

Java मोडेलले स्रोत मोडेल (चित्र 5) को रूपमा समान ह्यान्डल/बॉडी इडियम प्रयोग गर्दछ। IJavaElement ह्यान्डल हो, र JavaElementInfo ले शरीरको भूमिका खेल्छ। IJavaElement इन्टरफेसले सबै जाभा तत्वहरूमा सामान्य प्रोटोकल परिभाषित गर्दछ। यसका केही विधिहरू ह्यान्डल-मात्र हुन्: getElementName(), getParent(), आदि। JavaElementInfo वस्तुले सम्बन्धित तत्वको अवस्था भण्डार गर्छ: यसको संरचना र विशेषताहरू।

चामल। 5. IJavaElement र JavaElementInfo

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

मेमोरीमा तत्वहरूको सम्पूर्ण रूखलाई पूर्णतया भौतिक बनाउनबाट बच्नको लागि, जाभा मोडेल कार्यान्वयनले सीमित आकारको एलआरयू क्यास एलिमेन्ट जानकारीको प्रयोग गर्दछ, जहाँ कुञ्जी IJavaElement ह्यान्डल हो। एलिमेन्ट ट्री नेभिगेट गरिएको हुनाले एलिमेन्ट जानकारी वस्तुहरू मागमा सिर्जना गरिन्छ। यस अवस्थामा, कम से कम बारम्बार प्रयोग गरिएका वस्तुहरू क्यासबाट हटाइन्छ, र मोडेलको मेमोरी खपत निर्दिष्ट क्यास आकारमा सीमित रहन्छ। यो ह्यान्डल-आधारित डिजाइनको अर्को फाइदा हो, जसले ग्राहक कोडबाट यस्तो कार्यान्वयन विवरणहरू पूर्ण रूपमा लुकाउँछ।

जाभा तत्वहरूमा परिवर्तनहरू अधिसूचित गर्ने संयन्त्र सामान्यतया माथि छलफल गरिएको कार्यस्थान स्रोतहरूमा परिवर्तनहरू ट्र्याक गर्ने संयन्त्रसँग मिल्दोजुल्दो छ। जाभा मोडेलमा भएका परिवर्तनहरू निगरानी गर्न चाहने ग्राहकले सूचनाहरूको सदस्यता लिन्छ, जसलाई ElementChangedEvent वस्तुको रूपमा प्रतिनिधित्व गरिन्छ जसमा IJavaElementDelta (चित्र 6) हुन्छ।

चामल। 6. ElementChangedEvent र IJavaElementDelta

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

किनभने सिन्ट्याक्स रूखहरूले मेमोरीको महत्त्वपूर्ण मात्रा उपभोग गर्न सक्छ, JDT ले सक्रिय सम्पादकको लागि केवल एक AST क्यास गर्दछ। जाभा मोडेलको विपरीत, AST लाई सामान्यतया "मध्यवर्ती", "अस्थायी" मोडेलको रूपमा हेरिन्छ, जसका तत्वहरू ग्राहकहरूले सञ्चालनको सन्दर्भ बाहिरका सन्दर्भहरू राख्नु हुँदैन जसले AST को सिर्जनाको नेतृत्व गर्‍यो।

सूचीबद्ध तीन मोडेलहरू (जाभा मोडेल, AST, बाइन्डिङहरू) सँगै JDT मा "बुद्धिमान विकास उपकरणहरू" निर्माणको लागि आधार बनाउँदछ, विभिन्न "सहायकहरू" सहितको शक्तिशाली जाभा सम्पादक, स्रोत कोड प्रशोधनका लागि विभिन्न कार्यहरू (आयातको सूची व्यवस्थित गर्ने सहित। नाम र अनुकूलित शैली अनुसार ढाँचा), खोज र refactoring उपकरणहरू। यस अवस्थामा, जाभा मोडेलले विशेष भूमिका खेल्छ, किनकि यो अनुप्रयोगको संरचनाको विकासको दृश्य प्रतिनिधित्वको लागि आधारको रूपमा प्रयोग गरिन्छ (उदाहरणका लागि, प्याकेज एक्सप्लोरर, रूपरेखा, खोज, कल पदानुक्रम, र पदानुक्रम टाइप गर्नुहोस्)।

1C मा प्रयोग गरिएको ग्रहण कम्पोनेन्टहरू: उद्यम विकास उपकरणहरू

चित्रमा। चित्र 7 ले Eclipse कम्पोनेन्टहरू देखाउँछ जसले 1C: उद्यम विकास उपकरणहरूको लागि टेक्नोलोजी प्लेटफर्मको आधार बनाउँछ।

चामल। 7. 1C को लागि प्लेटफर्मको रूपमा ग्रहण: उद्यम विकास उपकरणहरू

ग्रहण प्लेटफर्म आधारभूत पूर्वाधार प्रदान गर्दछ। हामीले अघिल्लो खण्डमा यस पूर्वाधारका केही पक्षहरू हेरेका छौं।

ग्रहण मोडलिङ फ्रेमवर्क (EMF) संरचित डेटा मोडेलिङ को एक सामान्य माध्यम प्रदान गर्दछ। EMF Eclipse प्लेटफर्मसँग एकीकृत छ, तर नियमित Java अनुप्रयोगहरूमा पनि छुट्टै प्रयोग गर्न सकिन्छ। प्रायः, नयाँ Eclipse विकासकर्ताहरू पहिले नै EMF सँग राम्ररी परिचित छन्, यद्यपि तिनीहरूले ग्रहण प्लेटफर्मको जटिलताहरू पूर्ण रूपमा बुझ्दैनन्। यस्तो राम्रो-योग्य लोकप्रियता को कारणहरु मध्ये एक सार्वभौमिक डिजाइन हो, जसमा अन्य चीजहरु को बीचमा, एक एकीकृत मेटा-स्तर एपीआई समावेश छ, जसले तपाईलाई सामान्य तरिकामा कुनै पनि EMF मोडेल संग काम गर्न अनुमति दिन्छ। EMF द्वारा प्रदान गरिएको मोडेल वस्तुहरूको लागि आधारभूत कार्यान्वयनहरू र मेटा-मोडलमा आधारित मोडेल कोड उत्पन्न गर्नको लागि सबसिस्टमले विकासको गतिलाई उल्लेखनीय रूपमा बढाउँछ र त्रुटिहरूको संख्या घटाउँछ। EMF ले मोडेलहरू क्रमबद्ध गर्ने, मोडेलमा परिवर्तनहरू ट्र्याक गर्ने, र थप धेरैका लागि संयन्त्रहरू समावेश गर्दछ।

कुनै पनि साँच्चै सामान्य-उद्देश्य उपकरण जस्तै, EMF मोडेलिङ समस्याहरूको विस्तृत दायरा समाधान गर्न उपयुक्त छ, तर मोडेलका केही वर्गहरू (उदाहरणका लागि, माथि छलफल गरिएका ह्यान्डल-आधारित मोडेलहरू) लाई थप विशेष मोडलिङ उपकरणहरू आवश्यक पर्दछ। EMF को बारेमा कुरा गर्नु एक कृतज्ञ कार्य हो, विशेष गरी एउटा लेखको सीमित दायरा भित्र, किनकि यो छुट्टै पुस्तकको विषय हो, र बरु मोटो। केवल ध्यान दिनुहोस् कि EMF अन्तर्निहित सामान्यीकरणको उच्च-गुणस्तर प्रणालीले मोडलिङमा समर्पित परियोजनाहरूको सम्पूर्ण दायराको जन्मलाई अनुमति दिएको छ, जुन शीर्ष-स्तरको परियोजनामा ​​समावेश छ। ग्रहण मोडलिङ EMF आफैसँग। एउटा यस्तो परियोजना हो ग्रहण Xtext।

ग्रहण Xtext "पाठ मोडेलिङ" पूर्वाधार प्रदान गर्दछ। Xtext प्रयोग गर्दछ एएनटीएलआर स्रोत पाठ पार्स गर्न र परिणाम स्वरूप ASG (अमूर्त सिमान्टिक ग्राफ, जुन अनिवार्य रूपमा AST र बाइन्डिङहरूको संयोजन हो) को प्रतिनिधित्व गर्नका लागि EMF लाई "सिमान्टिक मोडेल" पनि भनिन्छ। Xtext द्वारा मोडेल गरिएको भाषाको व्याकरण Xtext को आफ्नै भाषामा वर्णन गरिएको छ। यसले तपाइँलाई ANTLR को लागि व्याकरण विवरण उत्पन्न गर्न मात्र होइन, तर AST क्रमिकरण संयन्त्र (अर्थात् Xtext ले पार्सर र अनपार्सर दुवै प्रदान गर्दछ), सन्दर्भ सङ्केत, र अन्य भाषा कम्पोनेन्टहरू प्राप्त गर्न अनुमति दिन्छ। अर्कोतर्फ, Xtext मा प्रयोग गरिएको व्याकरण भाषा ANTLR मा प्रयोग गरिएको व्याकरण भाषा भन्दा कम लचिलो छ। तसर्थ, कहिलेकाँही यो Xtext मा लागू गरिएको भाषा "मोड" गर्न आवश्यक छ, जुन सामान्यतया कुनै समस्या छैन यदि हामी भाषाको स्क्र्याचबाट विकास भइरहेको बारे कुरा गर्दैछौं, तर पहिले नै स्थापित वाक्य रचना भएको भाषाहरूको लागि अस्वीकार्य हुन सक्छ। यसका बावजुद, Xtext हाल ग्रहणमा प्रोग्रामिङ भाषाहरू र तिनीहरूका लागि विकास उपकरणहरू निर्माण गर्नको लागि सबैभन्दा परिपक्व, सुविधा सम्पन्न, र बहुमुखी उपकरण हो। विशेष गरी, यो द्रुत प्रोटोटाइपको लागि एक आदर्श उपकरण हो डोमेन-विशेष भाषाहरू (डोमेन-विशिष्ट भाषा, DSL)। ANTLR र EMF मा आधारित माथि उल्लेखित "भाषा कोर" को अतिरिक्त, Xtext ले अनुक्रमणिका संयन्त्र, वृद्धिशील निर्माण, एक "स्मार्ट सम्पादक", र धेरै, धेरै धेरै सहित धेरै उपयोगी उच्च-स्तर कम्पोनेन्टहरू प्रदान गर्दछ, तर ह्यान्डल छोड्छ- आधारित भाषा मोडेलहरू। EMF जस्तै, Xtext एउटा छुट्टै पुस्तकको योग्य विषय हो, र हामी अहिले यसको सबै क्षमताहरूको बारेमा संक्षिप्त रूपमा कुरा गर्न सक्दैनौं।

1C: उद्यम विकास उपकरणहरूले सक्रिय रूपमा EMF आफैं र अन्य ग्रहण मोडलिङ परियोजनाहरू दुवै प्रयोग गर्दछ। विशेष गरी, Xtext यस्तो 1C को लागि विकास उपकरणहरूको आधार हो: इन्टरप्राइज भाषाहरू निर्मित प्रोग्रामिङ भाषा र क्वेरी भाषाको रूपमा। यी विकास उपकरणहरूको लागि अर्को आधार Eclipse Handly परियोजना हो, जसलाई हामी थप विस्तारमा छलफल गर्नेछौं (सूचीबद्ध ग्रहण घटकहरूको, यो अझै पनि कम ज्ञात छ)।

ह्यान्डली ग्रहण, Eclipse टेक्नोलोजी शीर्ष-स्तरीय परियोजनाको एक उप-परियोजना, 1 मा 2014C द्वारा गरिएको ग्रहण फाउन्डेशनमा प्रारम्भिक कोड योगदानको परिणामको रूपमा देखा पर्‍यो। त्यसबेलादेखि, 1C ले परियोजनाको विकासलाई समर्थन गर्न जारी राखेको छ: ह्यान्डली कमिटरहरू कम्पनीका कर्मचारीहरू हुन्। परियोजना सानो छ, तर यसले Eclipse मा एक अद्वितीय स्थान ओगटेको छ: यसको मुख्य लक्ष्य ह्यान्डल-आधारित मोडेलहरूको विकासलाई समर्थन गर्नु हो।

ह्यान्डल-आधारित मोडेलहरूको आधारभूत वास्तु सिद्धान्तहरू, जस्तै ह्यान्डल/बॉडी इडियम, उदाहरणको रूपमा संसाधन मोडेल र जाभा मोडेल प्रयोग गरेर माथि छलफल गरिएको थियो। यसले यो पनि उल्लेख गर्यो कि रिसोर्स मोडेल र जाभा मोडेल दुबै एक्लिप्स जाभा डेभलपमेन्ट टूल्स (JDT) को लागि महत्त्वपूर्ण आधारहरू हुन्। र लगभग सबै *DT Eclipse परियोजनाहरूमा JDT जस्तै वास्तुकला भएको हुनाले, ग्रहण प्लेटफर्मको शीर्षमा बनाइएको सबै IDEs होइन भने, ह्यान्डल-आधारित मोडेलहरूले धेरैलाई अण्डरलाई दिन्छ भनेर भन्नु ठूलो अतिशयोक्ति हुनेछैन। उदाहरणका लागि, Eclipse C/C++ विकास उपकरण (CDT) सँग ह्यान्डल-आधारित C/C++ मोडेल छ जसले CDT वास्तुकलामा JDT मा Java मोडेलले जस्तै भूमिका खेल्छ।

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

यो होइन कि ग्रहणले यी मुद्दाहरू बुझेन। 2005 मा फिर्ता मार्टिन Aeschlimann, CDT प्रोटोटाइप विकास गर्ने अनुभव संक्षेप गर्दै, तर्क गरे ह्यान्डल-आधारित मोडेलहरू सहित भाषा मोडेलहरूको लागि साझा पूर्वाधार सिर्जना गर्न आवश्यक छ। तर, प्रायः जसरी हुन्छ, उच्च प्राथमिकताका कार्यहरूका कारण यी विचारहरूको कार्यान्वयन कहिले पनि हुन सकेको छैन। यसैबीच, *DT कोडको कारककरण अझै पनि ग्रहणमा अविकसित विषयहरू मध्ये एक हो।

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

• विषय क्षेत्र को मुख्य सार को पहिचान।
• प्रयास घटाउने र कोड पुन: प्रयोग मार्फत ह्यान्डल-आधारित भाषा मोडेलहरूको कार्यान्वयनको गुणस्तर सुधार गर्ने।
• नतिजा मोडेलहरूलाई एकीकृत मेटा-स्तर API प्रदान गर्दै, भाषा ह्यान्डल-आधारित मोडेलहरूसँग काम गर्ने साझा IDE कम्पोनेन्टहरू सिर्जना गर्न सम्भव बनाउँदै।
• लचिलोपन र स्केलेबिलिटी।
• Xtext सँग एकीकरण (अलग तहमा)।

साझा अवधारणा र प्रोटोकलहरू हाइलाइट गर्न, भाषा ह्यान्डल-आधारित मोडेलहरूको अवस्थित कार्यान्वयनहरू विश्लेषण गरियो। ह्यान्डलीद्वारा प्रदान गरिएका मुख्य इन्टरफेसहरू र आधारभूत कार्यान्वयनहरू चित्रमा देखाइएका छन्। ८।

चामल। 8. सामान्य इन्टरफेसहरू र ह्यान्डली तत्वहरूको आधारभूत कार्यान्वयनहरू

IElement इन्टरफेस एक तत्व को ह्यान्डल को प्रतिनिधित्व गर्दछ र सबै ह्यान्डली-आधारित मोडेल को तत्वहरु लाई सामान्य छ। एब्स्ट्र्याक्ट क्लास एलिमेन्टले सामान्यीकृत ह्यान्डल/बॉडी मेकानिज्म (चित्र ९) लागू गर्छ।

चामल। 9. IElement र जेनेरिक ह्यान्डल/बॉडी कार्यान्वयन

थप रूपमा, ह्यान्डलीले मोडेल तत्वहरूमा परिवर्तनहरू बारे सूचित गर्नको लागि सामान्यीकृत संयन्त्र प्रदान गर्दछ (चित्र 10)। तपाईले देख्न सक्नुहुने रूपमा, यो स्रोत मोडेल र जाभा मोडेलमा लागू गरिएको सूचना संयन्त्रसँग व्यापक रूपमा समान छ, र तत्व परिवर्तन जानकारीको एकीकृत प्रतिनिधित्व प्रदान गर्न IElementDelta प्रयोग गर्दछ।

चामल। 10. सामान्य इन्टरफेसहरू र ह्यान्डली सूचना संयन्त्रको आधारभूत कार्यान्वयनहरू

माथि छलफल गरिएको ह्यान्डली भाग (चित्र 9 र 10) लगभग कुनै पनि ह्यान्डल-आधारित मोडेलहरू प्रतिनिधित्व गर्न प्रयोग गर्न सकिन्छ। सिर्जनाको लागि भाषिक मोडेलहरू, परियोजनाले अतिरिक्त कार्यक्षमता प्रदान गर्दछ - विशेष गरी, सामान्य इन्टरफेसहरू र स्रोत पाठ संरचनाका तत्वहरूको लागि आधारभूत कार्यान्वयनहरू, तथाकथित। स्रोत तत्वहरू (चित्र 8)। ISourceFile इन्टरफेसले स्रोत फाइललाई प्रतिनिधित्व गर्दछ, र ISourceConstruct ले स्रोत फाइल भित्रको तत्वलाई प्रतिनिधित्व गर्दछ। अमूर्त वर्गहरू SourceFile र SourceConstruct ले स्रोत फाइलहरू र तिनीहरूका तत्वहरूसँग काम गर्न समर्थन गर्न सामान्यीकृत संयन्त्रहरू लागू गर्दछ, उदाहरणका लागि, पाठ बफरहरूसँग काम गर्ने, स्रोत पाठमा एक तत्वको समन्वयमा बाँधिने, कार्य प्रतिलिपि बफरको हालको सामग्रीहरूसँग मोडेलहरू मिलाउने। , आदि यी संयन्त्रहरू लागू गर्नु सामान्यतया चुनौतीपूर्ण हुन्छ, र ह्यान्डलीले उच्च गुणस्तरको आधार कार्यान्वयनहरू प्रदान गरेर ह्यान्डल-आधारित भाषा मोडेलहरू विकास गर्ने प्रयासलाई उल्लेखनीय रूपमा कम गर्न सक्छ।

माथि सूचीबद्ध कोर संयन्त्रहरूको अतिरिक्त, ह्यान्डलीले पाठ बफरहरू र स्न्यापशटहरूको लागि पूर्वाधार प्रदान गर्दछ, स्रोत कोड सम्पादकहरूसँग एकीकरणको लागि समर्थन (Xtext सम्पादकसँग बाहिरको बक्स एकीकरण सहित), साथै केही सामान्य UI कम्पोनेन्टहरू। स्रोत कोड सम्पादकहरूसँग काम गर्नुहोस्। ह्यान्डली मोडेलहरू जस्तै रूपरेखा फ्रेमवर्क। यसको क्षमताहरू चित्रण गर्न, परियोजनाले ह्यान्डलीमा जाभा मोडेलको कार्यान्वयन सहित धेरै उदाहरणहरू प्रदान गर्दछ। (JDT मा जाभा मोडेलको पूर्ण कार्यान्वयनको तुलनामा, यो मोडेल जानाजानी अधिक स्पष्टताको लागि केही हदसम्म सरलीकृत गरिएको छ।)

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

सिद्धान्तमा, ह्यान्डल-आधारित मोडेलहरू "डिजाइनद्वारा" राम्रोसँग मापन गर्छन्। उदाहरणका लागि, ह्यान्डल/शरीर मुहावराले तपाईंलाई मोडेलद्वारा खपत हुने मेमोरीको मात्रा सीमित गर्न अनुमति दिन्छ। तर त्यहाँ पनि nuances छन्। यसरी, स्केलेबिलिटीको लागि ह्यान्डली परीक्षण गर्दा, सूचना संयन्त्रको कार्यान्वयनमा समस्या पत्ता लाग्यो - जब धेरै संख्यामा तत्वहरू परिवर्तन गरियो, डेल्टा निर्माण गर्न धेरै समय लाग्यो। यो पत्ता लाग्यो कि समान समस्या JDT Java मोडेलमा अवस्थित थियो, जसबाट सम्बन्धित कोड एक पटक अनुकूलित भएको थियो। हामीले ह्यान्डलीमा बग फिक्स गर्यौं र JDT को लागि समान प्याच तयार गर्‍यौं, जुन कृतज्ञतापूर्वक प्राप्त भयो। यो केवल एउटा उदाहरण हो जहाँ अवस्थित मोडेल कार्यान्वयनहरूमा ह्यान्डली परिचय गराउनु सम्भावित रूपमा उपयोगी हुन सक्छ, किनकि यस अवस्थामा यस्तो बगलाई एक ठाउँमा फिक्स गर्न सकिन्छ।

प्राविधिक रूपमा अवस्थित मोडेल कार्यान्वयनमा ह्यान्डली कार्यान्वयन गर्नको लागि, पुस्तकालयमा महत्त्वपूर्ण लचिलोपन हुनुपर्छ। मुख्य समस्या एपीआई मोडेल भर पछाडि अनुकूलता कायम राख्नु हो। मा यो समस्या हल भयो ह्यान्डली ०.५ पुस्तकालयद्वारा प्रदान गरिएको एकीकृत मेटा-स्तर API बाट विकासकर्ताद्वारा परिभाषित र पूर्ण रूपमा नियन्त्रण गरिएको मोडेल-विशिष्ट API लाई स्पष्ट रूपमा अलग गरेर। यसले प्राविधिक रूपमा अवस्थित कार्यान्वयनहरूमा ह्यान्डली लागू गर्न सम्भव मात्र बनाउँदैन, तर नयाँ मोडेल विकासकर्तालाई API डिजाइन गर्दा महत्त्वपूर्ण स्वतन्त्रता पनि दिन्छ।

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

हालको संस्करण ह्यान्डली ०.५ डिसेम्बर 2016 मा बाहिर आयो। परियोजना हाल इन्क्युबेशनको अवस्थामा छ भन्ने तथ्यको बावजुद र API अझै अन्तमा निश्चित गरिएको छैन, Handly पहिले नै दुई ठूला व्यावसायिक उत्पादनहरूमा प्रयोग भइसकेको छ जसले "प्रारम्भिक अपनाउनेहरू" को रूपमा काम गर्ने जोखिम लिएको थियो, र, मैले भन्नै पर्छ, अझै पछुताउनु पर्दैन।

माथि उल्लेख गरिएझैं, यी उत्पादनहरू मध्ये एक हो 1C: उद्यम विकास उपकरण, जहाँ ह्यान्डलीलाई सुरुदेखि नै 1C को उच्च-स्तर संरचनाको मोडेल तत्वहरूमा प्रयोग गरिन्छ: इन्टरप्राइज भाषाहरू निर्मित प्रोग्रामिङ भाषा र क्वेरी भाषाको रूपमा। । अर्को उत्पादन सामान्य जनतालाई कम थाहा छ। यो कोडसिप स्टुडियो, एप्लिकेसन-विशेष निर्देशन-सेट प्रोसेसर (ASIP) को लागि एक एकीकृत डिजाइन वातावरण, दुबै चेक कम्पनी Codasip भित्र र यसको ग्राहकहरु द्वारा प्रयोग गरिन्छ, सहित। AMD, AVG, फर्नीचर, सिग्मा डिजाइन। Codasip 2015 देखि उत्पादनमा Handly प्रयोग गर्दै आएको छ, संस्करण Handly 0.2 बाट सुरु हुँदै। Codasip स्टुडियोको पछिल्लो रिलीजले संस्करण 0.5 प्रयोग गर्दछ, जुन 2016 मा जारी भयो। Codasip मा IDE विकासको नेतृत्व गर्ने Ondřej Ilčík परियोजनासँग सम्पर्कमा छन्, "तेस्रो पक्ष अपनाउने" को तर्फबाट महत्त्वपूर्ण प्रतिक्रिया प्रदान गर्दै। उसले यस परियोजनाको विकासमा प्रत्यक्ष रूपमा भाग लिन केही खाली समय खोज्न पनि सक्षम थियो, एउटा ह्यान्डली उदाहरणहरू मध्ये एउटा, जाभा मोडेलको लागि UI तह (कोडको ~ 4000 लाइनहरू) लागू गर्दै। अपनाउनेहरू द्वारा ह्यान्डलीको प्रयोगको बारेमा थप विस्तृत पहिलो-हात जानकारी पृष्ठमा फेला पार्न सकिन्छ सफलता कथाहरू परियोजना।

हामी आशा गर्छौं कि एपीआई स्थिरताको ग्यारेन्टीको साथ संस्करण 1.0 जारी गरेपछि र इन्क्युबेशन अवस्था छोड्ने परियोजना, Handly मा नयाँ अपनाउनेहरू हुनेछन्। यस बीचमा, परियोजनाले API को परीक्षण र थप सुधार गर्न जारी राख्छ, प्रति वर्ष दुई "प्रमुख" रिलीजहरू जारी गर्दै - जुनमा (एक साथ ग्रहण रिलिजको रूपमा उही मिति) र डिसेम्बर, एक अनुमानित तालिका प्रदान गर्दछ जुन स्वीकारकर्ताहरूले भर पर्न सक्छन्। हामी यो पनि थप्न सक्छौं कि परियोजनाको "बग दर" लगातार कम स्तरमा रहन्छ र ह्यान्डलीले पहिलो संस्करणदेखि नै प्रारम्भिक अपनाउनेहरूको उत्पादनहरूमा भरपर्दो रूपमा काम गरिरहेको छ। Eclipse Handly को थप अन्वेषण गर्न, तपाईं प्रयोग गर्न सक्नुहुन्छ ट्यूटोरियल सुरु गर्दै и वास्तु अवलोकन.

स्रोत: www.habr.com