1C:Enterprise Development Tools အတွက် နည်းပညာပလက်ဖောင်းတစ်ခုအနေဖြင့် Eclipse

မနော၊ နေလကြတ်ခြင်း ထွေထွေထူးထူး မိတ်ဆက်ပေးစရာ မလိုတာကြာပြီ။ Eclipse Java ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများ (Eclipse Java development tools) ကြောင့် လူများစွာသည် Eclipse နှင့် ရင်းနှီးကြသည်။JDT) ၎င်းသည် developer အများစုသည် "Eclipse" နှင့် ဆက်စပ်နေသည့် လူကြိုက်များသော open-source Java IDE ဖြစ်သည်။ သို့သော် Eclipse သည် ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများ (Eclipse Platform) နှင့် JDT အပါအဝင် ၎င်း၏အခြေခံပေါ်တွင် တည်ဆောက်ထားသော IDE အများအပြားကို ပေါင်းစပ်ရန်အတွက် တိုးချဲ့နိုင်သော ပလက်ဖောင်းတစ်ခုဖြစ်သည်။ Eclipse သည် Eclipse ပရောဂျက်၊ Eclipse Platform နှင့် JDT ၏ ဖွံ့ဖြိုးတိုးတက်မှုကို ညှိနှိုင်းပေးသည့် ထိပ်တန်းပရောဂျက်ဖြစ်ပြီး Eclipse SDK ၊ ထိုဖွံ့ဖြိုးတိုးတက်မှု၏ ထွက်ပေါ်လာသောရလဒ်ဖြစ်သည်။ နောက်ဆုံးအနေဖြင့် Eclipse သည် Java ဖြင့်ရေးသားထားခြင်းမဟုတ်ဘဲ ဖွံ့ဖြိုးတိုးတက်ရေးဆိုင်ရာကိရိယာများနှင့် သက်ဆိုင်သော ပရောဂျက်များပါရှိသော ကြီးမားသောအသိုက်အဝန်းတစ်ခုပါရှိသော open-source Foundation တစ်ခုဖြစ်သည် (ဥပမာ၊ ပရောဂျက်များ Eclipse IoT и နေကြတ်သိပ္ပံ) Eclipse ၏ကမ္ဘာသည်အလွန်ကွဲပြားသည်။

သဘာဝ၏ခြုံငုံသုံးသပ်ချက်ဖြစ်သည့် ဤဆောင်းပါးတွင်၊ Eclipse ဗိသုကာလက်ရာ၏ အခြေခံအချို့ကို ပေါင်းစပ်ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများတည်ဆောက်ရန်အတွက် ပလပ်ဖောင်းတစ်ခုအဖြစ် ကျွန်ုပ်တို့ကြိုးစားပြီး နည်းပညာ၏အခြေခံအုတ်မြစ်ဖြစ်သော Eclipse အစိတ်အပိုင်းများကို ကနဦးစိတ်ကူးတစ်ခုပေးပါမည်။ "ပြင်ဆင်မှုအသစ်" 1C: လုပ်ငန်းအတွက် ပလပ်ဖောင်း။ 1C: လုပ်ငန်းဖွံ့ဖြိုးတိုးတက်ရေး ကိရိယာများ. ကျွန်ုပ်တို့သည် Eclipse ဆော့ဖ်ဝဲရေးသားသူများကို ပစ်မှတ်ပရိသတ်အဖြစ်သာမက Eclipse developer များကိုသာ အာရုံစိုက်နေသောကြောင့် အပါအဝင်၊ ထိုသို့သောသုံးသပ်ချက်သည် ကြီးမားသောအပေါ်ယံနှင့် အကန့်အသတ်ဖြင့် မလွှဲမရှောင်သာဖြစ်လိမ့်မည်။ သို့သော်၊ အတွေ့အကြုံရှိ Eclipse developer များပင်လျှင် ဆောင်းပါးတွင် စိတ်ဝင်စားဖွယ်အချက်အလက်များကို ရှာဖွေနိုင်လိမ့်မည်ဟု မျှော်လင့်ပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် အတော်လေးသစ်လွင်ပြီး လူသိနည်းသော ပရောဂျက်တစ်ခုဖြစ်သည့် "နေကြတ်ခြင်း၏လျှို့ဝှက်ချက်များ" အကြောင်းပြောပါမည်။ Eclipse Handly1C မှ တည်ထောင်ပြီး ပံ့ပိုးခဲ့သည်။

Eclipse Architecture မိတ်ဆက်

ဥပမာကို အသုံးပြု၍ Eclipse ဗိသုကာ၏ ယေဘုယျရှုထောင့်အချို့ကို ဦးစွာကြည့်ကြပါစို့ Eclipse Java ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများ (JDT)။ ဥပမာတစ်ခုအနေဖြင့် JDT ကိုရွေးချယ်ခြင်းသည် မတော်တဆမဟုတ်ပါ။ ဤသည်မှာ Eclipse တွင် ပထမဆုံး ပေါင်းစပ်ထားသော ဖွံ့ဖြိုးတိုးတက်မှု ပတ်ဝန်းကျင်ဖြစ်သည်။ Eclipse C/C++ Development Tooling (CDT) ကဲ့သို့သော အခြားသော *DT Eclipse ပရောဂျက်များကို နောက်ပိုင်းတွင် ဖန်တီးခဲ့ပြီး JDT မှ အခြေခံဗိသုကာဆိုင်ရာ အခြေခံမူများနှင့် တစ်ဦးချင်းအရင်းအမြစ်ကုဒ်အပိုင်းအစများကို ငှားရမ်းခဲ့သည်။ JDT တွင်ဖော်ပြထားသော ဗိသုကာပညာ၏အခြေခံများသည် 1C:Enterprise Development Tools အပါအဝင် Eclipse Platform ၏ထိပ်တွင်တည်ဆောက်ထားသော IDE တိုင်းနီးပါးအတွက် ယနေ့ခေတ်နှင့်သက်ဆိုင်ပါသည်။

ပထမဦးစွာ၊ Eclipse သည် သီးခြားပရိုဂရမ်းမင်းဘာသာစကားများကို ပံ့ပိုးပေးရန်အတွက် ဒီဇိုင်းထုတ်ထားသော လုပ်ဆောင်နိုင်စွမ်းမှ ဘာသာစကား-လွတ်လပ်သောလုပ်ဆောင်နိုင်စွမ်းကို ပိုင်းခြားထားပြီး UI-အမှီအခိုကင်းသော “core” အစိတ်အပိုင်းများကို ဆက်စပ်နေသော အစိတ်အပိုင်းများမှ UI-အမှီအခိုကင်းသော “core” အစိတ်အပိုင်းများကို ခွဲထုတ်ခြင်းဖြင့် ထင်ရှားသောဗိသုကာအလွှာဖြင့် လက္ခဏာဆောင်ကြောင်း သတိပြုသင့်သည်။ အသုံးပြုသူအင်တာဖေ့စ်ပံ့ပိုးမှုနှင့်အတူ။

ထို့ကြောင့် Eclipse Platform သည် အများအားဖြင့် ဘာသာစကား-လွတ်လပ်သော အခြေခံအဆောက်အအုံကို သတ်မှတ်ပေးထားပြီး Java ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများသည် Eclipse တွင် အင်္ဂါရပ်အပြည့်ရှိသော Java IDE ကို ထည့်သွင်းထားသည်။ Eclipse Platform နှင့် JDT နှစ်ခုလုံးတွင် အစိတ်အပိုင်းများစွာ ပါဝင်ပြီး တစ်ခုစီသည် UI-လွတ်လပ်သော “core” သို့မဟုတ် UI အလွှာ (ပုံ 1) မှ ပါဝင်ပါသည်။

ထမင်း။ 1. Eclipse Platform နှင့် JDT

Eclipse Platform ၏ အဓိက အစိတ်အပိုင်းများကို စာရင်းပြုစုကြပါစို့။

• runtime — plugin အခြေခံအဆောက်အအုံကို သတ်မှတ်သည်။ နေကြတ်ခြင်းကို မော်ဂျူလာဗိသုကာဖြင့် သွင်ပြင်လက္ခဏာရှိသည်။ အခြေခံအားဖြင့် Eclipse သည် "extension point" နှင့် "extensions" များစုစည်းမှုတစ်ခုဖြစ်သည်။
• အလုပ်နေရာ - တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ပရောဂျက်များကို စီမံခန့်ခွဲပါ။ ပရောဂျက်တစ်ခုတွင် ဖိုင်စနစ်သို့ တိုက်ရိုက်ပုံဖော်ထားသည့် ဖိုင်တွဲများနှင့် ဖိုင်များ ပါဝင်သည်။
• Standard Widget Toolkit (SWT) - လည်ပတ်မှုစနစ်နှင့် ပေါင်းစပ်ထားသော အခြေခံ user interface အစိတ်အပိုင်းများကို ပံ့ပိုးပေးသည်။
• JFace — SWT ၏ထိပ်တွင်တည်ဆောက်ထားသော UI မူဘောင်များစွာကို ပံ့ပိုးပေးသည်။
• လုပျခှငျ — Eclipse UI ပါရာဒိုင်းကို သတ်မှတ်သည်- တည်းဖြတ်သူများ၊ အမြင်များ၊ ရှုထောင့်များ။

Eclipse Platform သည် Debug၊ Compare၊ Search နှင့် Team အပါအဝင် ပေါင်းစပ်ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများကို တည်ဆောက်ရန်အတွက် အခြားအသုံးဝင်သော အစိတ်အပိုင်းများစွာကိုလည်း ပံ့ပိုးပေးသည်ဟု ဆိုရပါမည်။ အရင်းအမြစ်ကုဒ်၏ "စမတ်တည်းဖြတ်သူများ" တည်ဆောက်ခြင်းအတွက် အခြေခံဖြစ်သော JFace Text ဖြင့် အထူးဖော်ပြသင့်သည်။ ကံမကောင်းစွာပဲ၊ ဤအစိတ်အပိုင်းများအပြင် UI အလွှာအစိတ်အပိုင်းများကို ဆန်းစစ်လေ့လာခြင်းပင်လျှင် ဤဆောင်းပါး၏နယ်ပယ်အတွင်း မဖြစ်နိုင်သောကြောင့် ဤအပိုင်း၏ကျန်ရှိသော အဓိက "core" အစိတ်အပိုင်းများ၏ ခြုံငုံသုံးသပ်ချက်ကို ကျွန်ုပ်တို့ကိုယ်တိုင် ကန့်သတ်လိုက်ပါမည်။ Eclipse Platform နှင့် JDT

Core Runtime

Eclipse plugin အခြေခံအဆောက်အဦသည် အခြေခံဖြစ်သည်။ OSGi ပရောဂျက်က ပံ့ပိုးပေးတယ်။ နေကြတ်ခြင်း Equinox. Eclipse plugin တစ်ခုစီသည် OSGi အတွဲတစ်ခုဖြစ်သည်။ OSGi သတ်မှတ်ချက်သည် အထူးသဖြင့် ဗားရှင်းပြုလုပ်ခြင်းနှင့် မှီခိုမှုဖြေရှင်းခြင်းအတွက် ယန္တရားများကို သတ်မှတ်သည်။ ဤစံယန္တရားများအပြင် Equinox သည် အယူအဆကို မိတ်ဆက်ပေးသည်။ တိုးချဲ့အချက်များ. ပလပ်အင်တစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင် တိုးချဲ့မှုအမှတ်များကို သတ်မှတ်နိုင်ပြီး တူညီသော သို့မဟုတ် အခြားပလပ်အင်များက သတ်မှတ်ထားသော တိုးချဲ့မှုအမှတ်များကို အသုံးပြုကာ စနစ်သို့ ထပ်လောင်းလုပ်ဆောင်နိုင်စွမ်း (“နောက်ဆက်တွဲများ”) ကိုလည်း မိတ်ဆက်ပေးနိုင်သည်။ OSGi နှင့် Equinox ယန္တရားများ၏ အသေးစိတ်ဖော်ပြချက်သည် ဤဆောင်းပါး၏ နယ်ပယ်ထက်ကျော်လွန်ပါသည်။ Eclipse တွင် modularization သည် စုစုပေါင်းဖြစ်သည် (Runtime အပါအဝင် မည်သည့်စနစ်ခွဲမဆို၊ တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော plugin များပါရှိသည်) နှင့် Eclipse ရှိ အရာအားလုံးနီးပါးသည် extension တစ်ခုဖြစ်သည်။ ထို့အပြင်၊ ဤအခြေခံမူများကို OSGi မမိတ်ဆက်မီ ကြာမြင့်စွာကတည်းက Eclipse ဗိသုကာတွင် မြှုပ်နှံထားပါသည် (ထိုအချိန်က ၎င်းတို့၏ကိုယ်ပိုင်နည်းပညာကို အသုံးပြုခဲ့ကြသည်၊ OSGi နှင့် အလွန်ဆင်တူသည်)။

Core Workspace

Eclipse Platform ၏ထိပ်တွင်တည်ဆောက်ထားသောပေါင်းစပ်ဖွံ့ဖြိုးတိုးတက်မှုပတ်ဝန်းကျင်အားလုံးနီးပါးသည် Eclipse workspace နှင့်အလုပ်လုပ်သည်။ ၎င်းသည် IDE တွင် ဖန်တီးထားသော အပလီကေးရှင်း၏ အရင်းအမြစ်ကုဒ်များ ပါလေ့ရှိသော အလုပ်ခွင်ဖြစ်သည်။ Workspace သည် ဖိုင်စနစ်သို့ တိုက်ရိုက်မြေပုံဖြစ်ပြီး ဖိုင်တွဲများနှင့် ဖိုင်များပါရှိသော ပရောဂျက်များ ပါဝင်သည်။ ဤပရောဂျက်များ၊ ဖိုင်တွဲများနှင့် ဖိုင်များကို ခေါ်သည်။ အရင်းအမြစ်များ အလုပ်ခွင်။ Eclipse ရှိ workspace အကောင်အထည်ဖော်မှုသည် ဖိုင်စနစ်နှင့်စပ်လျဉ်းသည့် ကက်ရှ်တစ်ခုအဖြစ် လုပ်ဆောင်ပြီး အရင်းအမြစ်သစ်ပင်၏ ဖြတ်ကျော်မှုကို သိသိသာသာ အရှိန်မြှင့်နိုင်စေသည်။ ထို့အပြင်၊ အလုပ်ခွင်အပါအဝင် နောက်ထပ်ဝန်ဆောင်မှုများစွာကို ပံ့ပိုးပေးပါသည်။ အရင်းအမြစ်ပြောင်းလဲမှုများအတွက် အသိပေးချက် ယန္တရား и တိုးမြှင့်တည်ဆောက်သူ အခြေခံအဆောက်အဦ.

Core Resources အစိတ်အပိုင်း (org.eclipse.core.resources plugin) သည် အလုပ်နေရာနှင့် ၎င်း၏အရင်းအမြစ်များကို ပံ့ပိုးပေးရန်အတွက် တာဝန်ရှိပါသည်။ အထူးသဖြင့်၊ ဤအစိတ်အပိုင်းသည် ဖောင်ရှိ အလုပ်ခွင်သို့ ပရိုဂရမ်စနစ်ဖြင့် ဝင်ရောက်ခွင့်ကို ပေးသည်။ အရင်းအမြစ်မော်ဒယ်များ. ဤပုံစံဖြင့် ထိထိရောက်ရောက်အလုပ်လုပ်ရန်၊ ဖောက်သည်များသည် အရင်းအမြစ်တစ်ခုသို့ လင့်ခ်တစ်ခုတင်ပြရန် ရိုးရှင်းသောနည်းလမ်းတစ်ခု လိုအပ်ပါသည်။ ဤကိစ္စတွင်၊ မော်ဒယ်တွင် အရင်းအမြစ်၏အခြေအနေကို တိုက်ရိုက်သိမ်းဆည်းသည့် အရာအား client ဝင်ရောက်ခြင်းမှ ဖုံးကွယ်ထားရန် နှစ်လိုဖွယ်ကောင်းသည်။ မဟုတ်ပါက၊ ဥပမာ၊ ဖိုင်တစ်ခုကိုဖျက်ခြင်းကိစ္စတွင်၊ client သည် နောက်ဆက်တွဲပြဿနာများနှင့်အတူ မော်ဒယ်တွင်မရှိတော့သော အရာတစ်ခုကို ဆက်လက်ထိန်းသိမ်းထားနိုင်သည်။ Eclipse ဟုခေါ်သော အရာတစ်ခုကို အသုံးပြု၍ ဤပြဿနာကို ဖြေရှင်းပေးပါသည်။ ကိုင်တွယ် အရင်းအမြစ်။ Handle သည် သော့တစ်ခုအနေဖြင့် လုပ်ဆောင်သည် (၎င်းသည် အလုပ်ခွင်ရှိ အရင်းအမြစ်သို့ လမ်းကြောင်းကို သိရုံမျှသာဖြစ်သည်) နှင့် အရင်းအမြစ်၏ အခြေအနေနှင့်ပတ်သက်သော အချက်အလက်များကို တိုက်ရိုက်သိမ်းဆည်းပေးသည့် အတွင်းပိုင်းမော်ဒယ်အရာဝတ္တုသို့ ဝင်ရောက်ခွင့်ကို လုံးလုံးထိန်းချုပ်ပါသည်။ ဤဒီဇိုင်းသည် ပုံစံကွဲတစ်မျိုးဖြစ်သည်။ လက်ကိုင်/ကိုယ်ထည်.

ထမင်း။ ပုံ 2 သည် အရင်းအမြစ်ပုံစံတွင် အသုံးပြုထားသည့်အတိုင်း Handle/Body idiom ကို သရုပ်ဖော်သည်။ IResource အင်တာဖေ့စ်သည် အရင်းအမြစ်တစ်ခု၏ လက်ကိုင်ကို ကိုယ်စားပြုပြီး ဤအင်တာဖေ့စ်ကို အကောင်အထည်ဖော်သည့် Resource အတန်းအစားနှင့် API များမဟုတ်သည့် ကိုယ်ထည်ကို ကိုယ်စားပြုသည့် ResourceInfo အတန်းအစား API တစ်ခုဖြစ်သည်။ workspace root နှင့် ဆက်စပ်သော အရင်းအမြစ်ဆီသို့ လမ်းကြောင်းကိုသာလျှင် သိရှိပြီး အရင်းအမြစ်အချက်အလက်သို့ လင့်ခ်တစ်ခုမပါဝင်ကြောင်း ကျွန်ုပ်တို့ အလေးပေးဖော်ပြပါသည်။ အရင်းအမြစ်အချက်အလက်အရာဝတ္ထုများသည် "ဒြပ်သစ်ပင်" ဟုခေါ်သည်။ ဤဒေတာဖွဲ့စည်းပုံသည် မှတ်ဉာဏ်တွင် လုံးဝရုပ်လုံးပေါ်လာသည်။ လက်ကိုင်တစ်ခုနှင့် သက်ဆိုင်သည့် အရင်းအမြစ်အချက်အလက်များကို ရှာဖွေရန်၊ ဒြပ်စင်သစ်ပင်သည် ထိုလက်ကိုင်တွင် သိမ်းဆည်းထားသော လမ်းကြောင်းအတိုင်း ဖြတ်သန်းသွားမည်ဖြစ်သည်။

ထမင်း။ 2. IResource နှင့် ResourceInfo

နောက်ပိုင်းတွင် ကျွန်ုပ်တို့မြင်တွေ့ရသည့်အတိုင်း၊ အရင်းအမြစ်မော်ဒယ်၏ အခြေခံဒီဇိုင်းကို အခြားမော်ဒယ်များအတွက် Eclipse တွင်လည်း အသုံးပြုထားသည်။ ယခုအချိန်တွင်၊ ဤဒီဇိုင်း၏ထူးခြားသောဂုဏ်သတ္တိအချို့ကိုဖော်ပြကြပါစို့။

• လက်ကိုင်သည် တန်ဖိုးရှိသော အရာဝတ္ထုတစ်ခုဖြစ်သည်။ တန်ဖိုးအရာဝတ္ထုများသည် အထောက်အထားအပေါ်အခြေခံ၍ တန်းတူညီမျှမှုမရှိသော မပြောင်းလဲနိုင်သော အရာများဖြစ်သည်။ ထိုအရာများကို hashed containers တွင် သော့တစ်ခုအဖြစ် လုံခြုံစွာအသုံးပြုနိုင်ပါသည်။ ကိုင်တွယ်မှုအများအပြားသည် တူညီသောအရင်းအမြစ်ကို ကိုးကားနိုင်သည်။ ၎င်းတို့ကို နှိုင်းယှဉ်ရန် ညီမျှခြင်း(Object) နည်းလမ်းကို အသုံးပြုရန် လိုအပ်သည်။
• Handle သည် အရင်းအမြစ်တစ်ခု၏ အပြုအမူကို သတ်မှတ်သည်၊ သို့သော် အရင်းအမြစ်၏ အခြေအနေနှင့်ပတ်သက်သည့် အချက်အလက် မပါဝင်ပါ (၎င်းသိမ်းဆည်းထားသည့် တစ်ခုတည်းသောဒေတာမှာ "သော့" ဖြစ်သည်၊ အရင်းအမြစ်သို့ လမ်းကြောင်း)။
• Handle သည် မတည်ရှိသော ရင်းမြစ် (မဖန်တီးရသေးသော အရင်းအမြစ် သို့မဟုတ် ဖျက်ပြီးသား အရင်းအမြစ်) ကို ရည်ညွှန်းနိုင်သည်။ အရင်းအမြစ်တစ်ခု၏တည်ရှိမှုကို IResource.exists() နည်းလမ်းကို အသုံးပြု၍ စစ်ဆေးနိုင်သည်။
• အချို့သော လုပ်ဆောင်ချက်များသည် လက်ကိုင်တွင် သိမ်းဆည်းထားသော အချက်အလက်ပေါ်တွင်သာ အခြေခံ၍ အကောင်အထည်ဖော်နိုင်သည် (ကိုင်တွယ်-သပ်သပ် လုပ်ဆောင်မှုများဟု ခေါ်သည်)။ ဥပမာများမှာ IRResource.getParent(), getFullPath(), etc. ထိုသို့သောလုပ်ငန်းအောင်မြင်ရန်အတွက် အရင်းအမြစ်သည် ရှိရန်မလိုအပ်ပါ။ အောင်မြင်ရန် အရင်းအမြစ်တစ်ခုရှိရန် လိုအပ်သော လုပ်ဆောင်ချက်များသည် အရင်းအမြစ်မရှိပါက CoreException ကို ပစ်ချပါ။

Eclipse သည် အလုပ်နေရာ အရင်းအမြစ်ပြောင်းလဲမှုများကို အသိပေးရန်အတွက် ထိရောက်သော ယန္တရားတစ်ခု ပံ့ပိုးပေးသည် (ပုံ 3)။ အရင်းအမြစ်များသည် Eclipse IDE အတွင်း လုပ်ဆောင်မှုများကြောင့် သို့မဟုတ် ဖိုင်စနစ်နှင့် ထပ်တူပြုခြင်း၏ ရလဒ်အဖြစ် ပြောင်းလဲနိုင်သည်။ ဖြစ်ရပ်နှစ်ခုစလုံးတွင်၊ အကြောင်းကြားချက်များကို စာရင်းသွင်းထားသည့် သုံးစွဲသူများအား "အရင်းအမြစ်မြစ်ဝကျွန်းပေါ်ဒေသ" ပုံစံဖြင့် ပြောင်းလဲမှုများအကြောင်း အသေးစိတ်အချက်အလက်များကို ပေးဆောင်ထားပါသည်။ မြစ်ဝကျွန်းပေါ်ဒေသသည် အလုပ်နေရာ အရင်းအမြစ် (သစ်ပင်ခွဲ) တစ်ခု၏ ပြည်နယ်နှစ်ခုကြားတွင် အပြောင်းအလဲများကို ဖော်ပြထားပြီး ၎င်းသည် အရင်းအမြစ်တစ်ခုသို့ ပြောင်းလဲမှုတစ်ခုကို ဖော်ပြသည့် အကွက်တစ်ခုစီတွင် တစ်ခုချင်းစီတွင် ကလေးအရင်းအမြစ်ဆိုင်ရာ အပြောင်းအလဲများကို ဖော်ပြသည့် နောက်အဆင့်တွင် deltas စာရင်းတစ်ခုပါရှိသည်။

ထမင်း။ 3. IResourceChangeEvent နှင့် IResourceDelta

အရင်းအမြစ်မြစ်ဝကျွန်းပေါ်အခြေခံသည့် အသိပေးချက်ယန္တရားတွင် အောက်ပါလက္ခဏာများ ရှိသည်။

• မြစ်ဝကျွန်းပေါ်ဒေသသည် recursive ဖွဲ့စည်းမှုနိယာမကို အသုံးပြု၍ တည်ဆောက်ထားသောကြောင့် တစ်ခုတည်းသော ပြောင်းလဲမှုနှင့် အပြောင်းအလဲများစွာကို တူညီသောဖွဲ့စည်းပုံကို အသုံးပြု၍ ဖော်ပြထားပါသည်။ စာရင်းသွင်းသူဖောက်သည်များသည် မြစ်ဝကျွန်းပေါ်သစ်ပင်မှတဆင့် အရင်းအမြစ်ပြောင်းလဲမှုသတိပေးချက်များကို စီမံဆောင်ရွက်နိုင်ပါသည်။
• မြစ်ဝကျွန်းပေါ်ဒေသတွင် ၎င်း၏ရွေ့လျားမှု နှင့်/သို့မဟုတ် ၎င်းနှင့်ဆက်စပ်နေသော “အမှတ်အသားများ” ဆိုင်ရာပြောင်းလဲမှုများအပါအဝင် အရင်းအမြစ်ဆိုင်ရာပြောင်းလဲမှုများနှင့်ပတ်သက်သည့် အချက်အလက်အပြည့်အစုံပါရှိသည် (ဥပမာ၊ စုစည်းမှုအမှားများကို အမှတ်အသားများအဖြစ် ကိုယ်စားပြုသည်)။
• အရင်းအမြစ်ကိုးကားချက်များကို လက်ကိုင်မှတစ်ဆင့် ပြုလုပ်ထားသောကြောင့်၊ မြစ်ဝကျွန်းပေါ်ဒေသသည် အဝေးမှ အရင်းအမြစ်တစ်ခုကို သဘာဝအတိုင်း ကိုးကားနိုင်သည်။

မကြာမီ ကျွန်ုပ်တို့မြင်ရတော့မည့်အတိုင်း၊ အရင်းအမြစ်မော်ဒယ်ပြောင်းလဲမှု အသိပေးချက်ယန္တရား၏ ဒီဇိုင်း၏အဓိကအစိတ်အပိုင်းများသည် အခြားလက်ကိုင်အခြေခံမော်ဒယ်များအတွက်လည်း သက်ဆိုင်ပါသည်။

JDT Core

Eclipse workspace အရင်းအမြစ်မော်ဒယ်သည် အခြေခံဘာသာစကား-ဘာသာမဲ့ပုံစံဖြစ်သည်။ JDT Core အစိတ်အပိုင်း (ပလပ်အင် org.eclipse.jdt.core) သည် Java ရှုထောင့်မှ အလုပ်ခွင်ဖွဲ့စည်းပုံအား လမ်းကြောင်းရှာဖွေခြင်းနှင့် ခွဲခြမ်းစိတ်ဖြာရန်အတွက် API တစ်ခု ပံ့ပိုးပေးသည့် “Java model” (Java မော်ဒယ်) ဤ API ကို ဖိုင်တွဲများနှင့် ဖိုင်များ၏ သတ်မှတ်ချက်များတွင် သတ်မှတ်ထားသည့် အရင်းခံအရင်းအမြစ်မော်ဒယ် API နှင့် ဆန့်ကျင်သည့်အနေဖြင့် Java ဒြပ်စင်များ၏ စည်းကမ်းချက်များဖြင့် သတ်မှတ်ထားသည်။ Java ဒြပ်စင်သစ်ပင်၏ အဓိက အင်တာဖေ့စ်များကို ပုံတွင် ပြထားသည်။ ၄။

ထမင်း။ 4. Java Model Elements များ

Java မော်ဒယ်သည် အရင်းအမြစ်ပုံစံ (ပုံ 5) ကဲ့သို့ လက်ကိုင်/ကိုယ်ခန္ဓာ idiom ကို အသုံးပြုသည်။ IJavaElement သည် လက်ကိုင်ဖြစ်ပြီး JavaElementInfo သည် ကိုယ်ခန္ဓာ၏အခန်းကဏ္ဍဖြစ်သည်။ IJavaElement အင်တာဖေ့စ်သည် Java ဒြပ်စင်အားလုံးအတွက် အသုံးများသော ပရိုတိုကောကို သတ်မှတ်သည်။ ၎င်း၏နည်းလမ်းအချို့မှာ ကိုင်တွယ်-သပ်သပ်ဖြစ်သည်- getElementName(), getParent(), etc. JavaElementInfo အရာဝတ္ထုသည် သက်ဆိုင်ရာဒြပ်စင်၏ အခြေအနေကို သိမ်းဆည်းသည်- ၎င်း၏ဖွဲ့စည်းပုံနှင့် အရည်အချင်းများကို သိမ်းဆည်းထားသည်။

ထမင်း။ 5. IJavaElement နှင့် JavaElementInfo

Java မော်ဒယ်သည် အရင်းအမြစ် မော်ဒယ်နှင့် နှိုင်းယှဉ်ပါက အခြေခံ လက်ကိုင်/ကိုယ်ထည် ဒီဇိုင်းကို အကောင်အထည်ဖော်ရာတွင် ကွာခြားချက် အချို့ရှိသည်။ အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း၊ အရင်းအမြစ်ပုံစံတွင်၊ node များသည် အရင်းအမြစ်အချက်အလက်အရာဝတ္တုများဖြစ်ကြသော ဒြပ်စင်သစ်ပင်သည် မှတ်ဉာဏ်တွင် လုံး၀ပါဝင်ပါသည်။ သို့သော် Java မော်ဒယ်သည် .java နှင့် .class ဖိုင်များ၏ အတွင်းပိုင်းဖွဲ့စည်းပုံကို ကိုယ်စားပြုသောကြောင့်၊ အမျိုးအစားများ၊ အကွက်များနှင့် နည်းလမ်းများထက် များစွာကြီးမားသော အစိတ်အပိုင်းများ ရှိနိုင်ပါသည်။

မှတ်ဉာဏ်အတွင်းရှိ ဒြပ်စင်သစ်ပင်တစ်ခုလုံးကို လုံးဝအကောင်အထည်မဖော်စေရန်၊ Java မော်ဒယ်အကောင်အထည်ဖော်မှုသည် သော့သည် IJavaElement ကိုကိုင်တွယ်သည့် ကန့်သတ်အရွယ်အစား LRU ကက်ရှ်ကို အသုံးပြုထားသည်။ ဒြပ်စင်သစ်ပင်ကို လမ်းညွှန်ထားသောကြောင့် ဒြပ်စင်အချက်အလက်အရာဝတ္ထုများကို လိုအပ်ချက်အရ ဖန်တီးထားသည်။ ဤကိစ္စတွင်၊ အသုံးအနည်းဆုံးအရာများကို ကက်ရှ်မှ နှင်ထုတ်ပြီး မော်ဒယ်၏ မမ်မိုရီသုံးစွဲမှုသည် သတ်မှတ်ထားသော ကက်ရှ်အရွယ်အစားအထိ ကန့်သတ်ထားသည်။ ဤသည်မှာ သုံးစွဲသူကုဒ်မှ အကောင်အထည်ဖော်မှုအသေးစိတ်အချက်အလက်များကို လုံးဝဖုံးကွယ်ထားသည့် ကိုင်တွယ်အခြေခံဒီဇိုင်း၏ နောက်ထပ်အားသာချက်တစ်ခုဖြစ်သည်။

Java ဒြပ်စင်များအား အပြောင်းအလဲများကို အသိပေးသည့် ယန္တရားသည် ယေဘူယျအားဖြင့် အထက်တွင် ဆွေးနွေးခဲ့သည့် workspace အရင်းအမြစ်များဆိုင်ရာ အပြောင်းအလဲများကို ခြေရာခံသည့် ယန္တရားနှင့် ဆင်တူသည်။ Java မော်ဒယ်တွင် အပြောင်းအလဲများကို စောင့်ကြည့်လိုသော client သည် IJavaElementDelta (ပုံ 6) ပါရှိသော ElementChangedEvent အရာဝတ္ထုအဖြစ် ကိုယ်စားပြုထားသည့် အကြောင်းကြားချက်များကို စာရင်းသွင်းပါသည်။

ထမင်း။ 6. ElementChangedEvent နှင့် IJavaElementDelta

Java မော်ဒယ်တွင် နည်းလမ်းကောင်တာများ သို့မဟုတ် အမည်ဖြေရှင်းခြင်းဆိုင်ရာ အချက်အလက်မပါဝင်သောကြောင့် Java တွင် ရေးသားထားသော ကုဒ်အသေးစိတ်ခွဲခြမ်းစိတ်ဖြာမှုအတွက် JDT Core သည် နောက်ထပ် (လက်ကိုင်အခြေခံမဟုတ်သော) မော်ဒယ်ကို ပံ့ပိုးပေးသည်- စိတ္တဇအထားအသိုသစ်ပင် (စိတ္တဇအထားအသိုသစ်ပင်၊ AST)။ AST သည် အရင်းအမြစ်စာသားကိုခွဲခြမ်းစိတ်ဖြာခြင်း၏ရလဒ်ကိုကိုယ်စားပြုသည်။ AST nodes များသည် အရင်းအမြစ် module ၏ ဖွဲ့စည်းပုံ (ကြေငြာချက်များ၊ အော်ပရေတာများ၊ အသုံးအနှုန်းများ စသည်တို့) နှင့် သက်ဆိုင်ပြီး အရင်းအမြစ်စာသားတွင် သက်ဆိုင်ရာဒြပ်စင်များ၏ သြဒီနိတ်များအကြောင်း အချက်အလက်များအပြင် (ရွေးချယ်စရာတစ်ခုအနေဖြင့်) အချက်အလက်များပါရှိသည်။ links တွေကို ပုံစံတစ်မျိုးလို့ ခေါ်ပါတယ်။ ခညျြနှောငျ. Bindings များသည် compiler မှသိသော အမျိုးအစား၊ method နှင့် variable များကဲ့သို့ အမည်ပေးထားသော အရာများကို ကိုယ်စားပြုသည့် အရာများဖြစ်သည်။ သစ်ပင်ပုံစံ AST node များနှင့်မတူဘဲ၊ bindings များသည် cross-referencing ကို ပံ့ပိုးပေးပြီး ယေဘုယျအားဖြင့် ဂရပ်တစ်ခု ဖန်တီးသည်။ abstract class ASTNode သည် AST node အားလုံးအတွက် ဘုံအခြေခံလူတန်းစားဖြစ်သည်။ ASTNode အတန်းခွဲများသည် Java ဘာသာစကား၏ သီးခြား syntactic တည်ဆောက်မှုများနှင့် ကိုက်ညီသည်။

အထားအသိုသစ်များသည် မှတ်ဉာဏ်ပမာဏများစွာကို စားသုံးနိုင်သောကြောင့် JDT သည် တက်ကြွသောတည်းဖြတ်သူအတွက် AST တစ်ခုသာ သိမ်းဆည်းထားသည်။ Java မော်ဒယ်နှင့်မတူဘဲ၊ AST ကို ပုံမှန်အားဖြင့် AST ကိုဖန်တီးရန် ဦးတည်သည့် လုပ်ဆောင်ချက်၏ ဆက်စပ်မှုပြင်ပရှိ client များမှ အဖွဲ့ဝင်များအား ရည်ညွှန်းခြင်းမပြုသင့်သော "အလယ်အလတ်" "ယာယီ" မော်ဒယ်အဖြစ် ရှုမြင်ကြသည်။

စာရင်းသွင်းထားသော မော်ဒယ်သုံးမျိုး (Java model၊ AST၊ bindings) သည် JDT ရှိ "အသိဉာဏ်ရှိသော ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများ" ကို တည်ဆောက်ရန်အတွက် အခြေခံအဖြစ်၊ "helpers" အမျိုးမျိုးဖြင့် အစွမ်းထက်သော Java တည်းဖြတ်သူ၊ အရင်းအမြစ်ကုဒ်ကို လုပ်ဆောင်ရန်အတွက် လုပ်ဆောင်ချက်အမျိုးမျိုး (သွင်းကုန်စာရင်းကို စီစဉ်ခြင်းအပါအဝင်၊ စိတ်ကြိုက်ပုံစံအတိုင်း အမည်များနှင့် ဖော်မတ်ချခြင်း)၊ ရှာဖွေခြင်းနှင့် ပြန်လည်ပြင်ဆင်ခြင်း ကိရိယာများ။ ဤကိစ္စတွင်၊ Java မော်ဒယ်သည် အထူးအခန်းကဏ္ဍမှ ပါဝင်နေသောကြောင့် ၎င်းသည် တီထွင်နေသော အပလီကေးရှင်း၏ ဖွဲ့စည်းပုံကို မြင်သာထင်သာမြင်သာရှိသော ကိုယ်စားပြုမှုအတွက် အခြေခံအဖြစ်အသုံးပြုသည် (ဥပမာ၊ Package Explorer၊ Outline၊ Search၊ Call Hierarchy နှင့်၊ Hierarchy) ရိုက်ထည့်ပါ။

1C:Enterprise Developments Tools တွင်အသုံးပြုသော Eclipse အစိတ်အပိုင်းများ

ပုံတွင်။ ပုံ 7 သည် 1C:Enterprise Development Tools အတွက် နည်းပညာပလပ်ဖောင်း၏ အခြေခံအုတ်မြစ်ဖြစ်သော Eclipse အစိတ်အပိုင်းများကို ပြသထားသည်။

ထမင်း။ 7. Eclipse သည် 1C:Enterprise Development Tools အတွက် platform တစ်ခုအနေဖြင့်

နေကြတ်စင်္ကြာ အခြေခံအဆောက်အဦများ ထောက်ပံ့ပေးသည်။ ယခင်အပိုင်းတွင် ဤအခြေခံအဆောက်အအုံ၏ ရှုထောင့်အချို့ကို ကျွန်ုပ်တို့ကြည့်ရှုခဲ့သည်။

Eclipse Modeling Framework (EMF) စံနမူနာပြထားသော ဒေတာကို စံနမူနာပြုခြင်း၏ ယေဘုယျနည်းလမ်းကို ပံ့ပိုးပေးသည်။ EMF ကို Eclipse Platform နှင့် ပေါင်းစပ်ထားသော်လည်း ပုံမှန် Java အပလီကေးရှင်းများတွင်လည်း သီးခြားအသုံးပြုနိုင်ပါသည်။ မကြာခဏဆိုသလို Eclipse developer အသစ်များသည် Eclipse Platform ၏ ရှုပ်ထွေးမှုများကို အပြည့်အ၀နားမလည်သေးသော်လည်း EMF နှင့် ကောင်းစွာရင်းနှီးနေပြီဖြစ်သည်။ ဤကဲ့သို့ ထိုက်တန်သော လူကြိုက်များရခြင်း၏ အကြောင်းရင်းများထဲမှတစ်ခုမှာ ယေဘူယျအားဖြင့် သင်မည်သည့် EMF မော်ဒယ်နှင့်မဆို လုပ်ဆောင်နိုင်စေမည့် ပေါင်းစပ် meta-level API ပါ၀င်သည့် universal design ဖြစ်သည်။ EMF မှပံ့ပိုးပေးထားသော မော်ဒယ်အရာဝတ္ထုများအတွက် အခြေခံအကောင်အထည်ဖော်မှုများနှင့် meta-model ကိုအခြေခံ၍ မော်ဒယ်ကုဒ်ထုတ်ပေးသည့်စနစ်ခွဲများသည် ဖွံ့ဖြိုးတိုးတက်မှုအရှိန်ကို သိသိသာသာတိုးမြင့်စေပြီး အမှားအယွင်းအရေအတွက်ကို လျှော့ချပေးသည်။ EMF တွင် မော်ဒယ်များကို အမှတ်စဉ်ပြုလုပ်ရန်၊ မော်ဒယ်သို့ ပြောင်းလဲမှုများကို ခြေရာခံခြင်း နှင့် အခြားအရာများစွာ ပါဝင်ပါသည်။

အမှန်တကယ် ယေဘူယျသုံးသည့် ကိရိယာများကဲ့သို့ပင် EMF သည် ကျယ်ပြန့်သော မော်ဒယ်လ် ပြဿနာများကို ဖြေရှင်းရန်အတွက် သင့်လျော်သော်လည်း အချို့သော မော်ဒယ်များ (ဥပမာ၊ အထက်တွင် ဆွေးနွေးထားသော လက်ကိုင်အခြေခံ မော်ဒယ်များ) သည် ပိုမို အထူးပြု မော်ဒယ်လ် ကိရိယာများ လိုအပ်ပါသည်။ EMF အကြောင်း ပြောခြင်းသည် အထူးသဖြင့် ဆောင်းပါးတစ်ခု၏ ကန့်သတ်ကန့်သတ်ချက်များအတွင်း၌ ဤအရာသည် သီးခြားစာအုပ်၏ အကြောင်းအရာဖြစ်ပြီး အထူအပါးဖြစ်သောကြောင့် ဖြစ်သည်။ EMF ကို နောက်ခံပြုထားသော အရည်အသွေးမြင့် စနစ်သည် ထိပ်တန်းအဆင့် ပရောဂျက်တွင် ပါဝင်သော မော်ဒယ်ပြုလုပ်ခြင်းအတွက် ရည်ရွယ်သော ပရောဂျက်များ အားလုံးကို မွေးဖွားခွင့်ပြုကြောင်း သတိပြုကြပါစို့။ Eclipse Modeling EMF ကိုယ်တိုင်လည်း ပါပါတယ်။ ထိုကဲ့သို့သောပရောဂျက်တစ်ခုမှာ Eclipse Xtext ဖြစ်သည်။

Eclipse Xtext "စာသားပုံစံတည်ဆောက်ခြင်း" အခြေခံအဆောက်အဦကိုထောက်ပံ့ပေးသည်။ Xtext ကိုအသုံးပြုသည်။ ANTLR အရင်းအမြစ် စာသားနှင့် EMF ကို ခွဲခြမ်းစိတ်ဖြာရန်အတွက် ရလဒ် ASG (အခြေခံအားဖြင့် AST နှင့် bindings များပေါင်းစပ်ထားသော) မှ ထွက်ပေါ်လာသော ASG (စိတ္တဇ semantic ဂရပ်ဖစ်) ကို " semantic model" ဟုခေါ်သည်။ Xtext မှ ပုံစံထုတ်ထားသော ဘာသာစကား၏သဒ္ဒါကို Xtext ၏ကိုယ်ပိုင်ဘာသာစကားဖြင့် ဖော်ပြပါသည်။ ၎င်းသည် ANTLR အတွက် သဒ္ဒါဖော်ပြချက်တစ်ခုကို ဖန်တီးရုံသာမက AST နံပါတ်စဉ်သတ်မှတ်ခြင်း ယန္တရား (ဆိုလိုသည်မှာ Xtext သည် parser နှင့် unparser နှစ်ခုလုံးကို ပံ့ပိုးပေးသည်)၊ စကားစပ် အရိပ်အမြွက်နှင့် အခြားဘာသာစကား အစိတ်အပိုင်းများစွာကို ရရှိစေပါသည်။ အခြားတစ်ဖက်တွင်၊ Xtext တွင်အသုံးပြုသောသဒ္ဒါဘာသာစကားသည် ANTLR တွင်အသုံးပြုသည့်သဒ္ဒါဘာသာစကားထက် ပျော့ပြောင်းမှုနည်းသည်။ ထို့ကြောင့်၊ တစ်ခါတစ်ရံတွင်၊ ကျွန်ုပ်တို့သည် အစမှစတင်၍ တီထွင်ထားသော ဘာသာစကားတစ်ခုအကြောင်းပြောနေလျှင် များသောအားဖြင့် ပြဿနာမဟုတ်သော၊ အကောင်အထည်ဖော်ပြီးသားဘာသာစကားကို Xtext သို့ “ကွေး” ရန် လိုအပ်သည်၊ သို့သော် သတ်မှတ်ပြီးသား syntax ရှိသည့် ဘာသာစကားများအတွက် လက်မခံနိုင်ပါ။ ဤအရာများရှိနေသော်လည်း၊ Xtext သည် လက်ရှိတွင် ၎င်းတို့အတွက် ပရိုဂရမ်းမင်းဘာသာစကားများနှင့် ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများတည်ဆောက်ရန်အတွက် Eclipse တွင် အရင့်ကျက်ဆုံး၊ အင်္ဂါရပ်ကြွယ်ဝပြီး စွယ်စုံရသုံးနိုင်သောကိရိယာဖြစ်သည်။ အထူးသဖြင့်၊ ၎င်းသည် လျင်မြန်သော ပုံတူဖော်ခြင်းအတွက် စံပြကိရိယာတစ်ခုဖြစ်သည်။ ဒိုမိန်းအလိုက် ဘာသာစကားများ (ဒိုမိန်း-သီးသန့်ဘာသာစကား၊ DSL)။ ANTLR နှင့် EMF ကိုအခြေခံ၍ အထက်ဖော်ပြပါ “ဘာသာစကား core” အပြင်၊ Xtext သည် ညွှန်းကိန်းယန္တရားများ၊ တိုးမြှင့်တည်ဆောက်မှု၊ “စမတ်တည်းဖြတ်သူ” နှင့် အခြားအရာများစွာအပါအဝင် အသုံးဝင်သောအဆင့်မြင့်အစိတ်အပိုင်းများစွာကို ပံ့ပိုးပေးပါသည်။ အခြေခံဘာသာစကားမော်ဒယ်များ။ EMF ကဲ့သို့ပင်၊ Xtext သည် သီးခြားစာအုပ်တစ်အုပ်နှင့် ထိုက်တန်သည့် ဘာသာရပ်ဖြစ်ပြီး၊ ၎င်း၏ စွမ်းဆောင်နိုင်မှုအားလုံးကို ယခုအချိန်၌ပင် ကျွန်ုပ်တို့ အတိုချုံးပြော၍မရပါ။

1C:Enterprise Development Tools သည် EMF ကိုယ်တိုင်နှင့် အခြားသော Eclipse Modeling ပရောဂျက်များစွာကို တက်ကြွစွာ အသုံးပြုပါသည်။ အထူးသဖြင့်၊ Xtext သည် 1C:လုပ်ငန်းသုံးဘာသာစကားများအတွက် တပ်ဆင်ထားသော ပရိုဂရမ်းမင်းဘာသာစကားနှင့် query ဘာသာစကားကဲ့သို့ ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများ၏ အခြေခံအုတ်မြစ်များထဲမှ တစ်ခုဖြစ်သည်။ ဤဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများအတွက် နောက်ထပ်အခြေခံအချက်မှာ Eclipse Handly ပရောဂျက်ဖြစ်ပြီး၊ ပိုမိုအသေးစိတ်ဆွေးနွေးမည့် (Eclipse အစိတ်အပိုင်းများစာရင်းတွင်၊ ၎င်းသည် လူသိအနည်းဆုံးဖြစ်နေဆဲဖြစ်သည်)။

Eclipse HandlyEclipse Technology ၏ ထိပ်တန်းပရောဂျက်ခွဲတစ်ခုဖြစ်သည့် 1 ခုနှစ်တွင် 2014C မှပြုလုပ်သော Eclipse Foundation အတွက် ကနဦးကုဒ်ပံ့ပိုးမှုရလဒ်ကြောင့် ထွက်ပေါ်လာခဲ့သည်။ ထိုအချိန်မှစ၍ 1C သည် ပရောဂျက်၏ ဖွံ့ဖြိုးတိုးတက်မှုကို ဆက်လက်ပံ့ပိုးခဲ့သည်- Handly committers များသည် ကုမ္ပဏီ၏ဝန်ထမ်းများဖြစ်သည်။ ပရောဂျက်သည် သေးငယ်သော်လည်း Eclipse တွင် ထူးခြားသော အထူးအခွင့်အရေးကို သိမ်းပိုက်ထားသည်- ၎င်း၏ အဓိက ရည်မှန်းချက်မှာ လက်ကိုင်အခြေခံ မော်ဒယ်များ ဖွံ့ဖြိုးတိုးတက်ရေးကို ပံ့ပိုးပေးရန် ဖြစ်သည်။

လက်ကိုင်/ကိုယ်ထည် idiom ကဲ့သို့သော လက်ကိုင်အခြေပြု မော်ဒယ်များ၏ အခြေခံ ဗိသုကာဆိုင်ရာ အခြေခံမူများကို အရင်းအမြစ် မော်ဒယ်နှင့် Java မော်ဒယ်ကို နမူနာအဖြစ် အသုံးပြု၍ အထက်တွင် ဆွေးနွေးခဲ့သည်။ အရင်းအမြစ်မော်ဒယ်နှင့် Java မော်ဒယ်နှစ်ခုလုံးသည် Eclipse Java ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများ (JDT) အတွက် အရေးကြီးသော အခြေခံအုတ်မြစ်ဖြစ်ကြောင်းကိုလည်း မှတ်သားထားသည်။ *DT Eclipse ပရောဂျက်အားလုံးနီးပါးတွင် JDT နှင့်ဆင်တူသော ဗိသုကာလက်ရာများပါရှိသောကြောင့် Eclipse Platform ၏ထိပ်တွင်တည်ဆောက်ထားသော IDE များအားလုံးမဟုတ်ပါက လက်ကိုင်-based မော်ဒယ်များသည် အများအပြားကို နောက်ခံထားသည်ဟု ဆိုခြင်းသည် ကြီးကျယ်သောချဲ့ကားမှုမဟုတ်ပါ။ ဥပမာအားဖြင့်၊ Eclipse C/C++ Development Tooling (CDT) တွင် JDT တွင် Java မော်ဒယ်ကဲ့သို့ CDT ဗိသုကာလက်ရာတွင် တူညီသောအခန်းမှပါဝင်သည့် ကိုင်တွယ်အခြေခံ C/C++ မော်ဒယ်တစ်ခု ရှိသည်။

Handly မတိုင်မီတွင် Eclipse သည် ကိုင်တွယ်အသုံးပြုသည့် ဘာသာစကားပုံစံများကို တည်ဆောက်ရန်အတွက် အထူးပြုစာကြည့်တိုက်များကို မကမ်းလှမ်းခဲ့ပါ။ လက်ရှိတည်ရှိနေသော မော်ဒယ်များကို Java မော်ဒယ်ကုဒ် (aka copy/paste) တိုက်ရိုက် လိုက်လျောညီထွေဖြစ်အောင် ဖန်တီးထားခြင်းဖြစ်သည်။ ခွင့်ပြုတဲ့ကိစ္စတွေမှာ Eclipse Public License (EPL)။ (သေချာသည်မှာ၊ ဤသည်မှာ Eclipse သည် သူ့ဘာသာသူ ပရောဂျက်များအတွက် တရားဝင် ပြဿနာမဟုတ်ပါ၊ သို့သော် ပိတ်ထားသော ရင်းမြစ် ထုတ်ကုန်များအတွက် မဟုတ်ပါ။) ၎င်း၏ မွေးရာပါ အလိမ်အညာများအပြင်၊ ဤနည်းလမ်းသည် လူသိများသော ပြဿနာများကို မိတ်ဆက်ပေးသည်- အမှားများနှင့် လိုက်လျောညီထွေဖြစ်အောင် ပြုလုပ်သည့် ကုဒ်ပွားခြင်း၊ စသည်တို့ ပိုဆိုးတာက ရလဒ်ထွက်ပေါ်တဲ့ မော်ဒယ်တွေဟာ “သူတို့ကိုယ်သူတို့” ရှိနေကြပြီး ပေါင်းစည်းရေးအတွက် အလားအလာကို အခွင့်ကောင်းမယူကြဘဲ။ သို့သော် ကိုင်တွယ်အခြေခံဘာသာစကားမော်ဒယ်များအတွက် ဘုံသဘောတရားများနှင့် ပရိုတိုကောများကို သီးခြားခွဲထုတ်ခြင်းသည် EMF ၏ဖြစ်ရပ်နှင့်ဆင်တူသည်၊ ၎င်းတို့နှင့်အလုပ်လုပ်ရန်အတွက် ပြန်လည်အသုံးပြုနိုင်သောအစိတ်အပိုင်းများဖန်တီးမှုကိုဖြစ်ပေါ်စေနိုင်သည်။

Eclipse သည် ဤပြဿနာများကို နားမလည်သောကြောင့် မဟုတ်ပါ။ 2005 မှာ ပြန်သွားတယ်။ Martin AeschlimannCDT ရှေ့ပြေးပုံစံကို တီထွင်ခြင်း အတွေ့အကြုံ အကျဉ်းချုပ်၊ စောဒကတက်သည်။ ကိုင်တွယ်အခြေခံ မော်ဒယ်များအပါအဝင် ဘာသာစကားမော်ဒယ်များအတွက် ဘုံအခြေခံအဆောက်အအုံတစ်ခု ဖန်တီးရန် လိုအပ်ပါသည်။ သို့သော် မကြာခဏဆိုသလိုပင်၊ ဦးစားပေးလုပ်ဆောင်မှုများကြောင့် ဤစိတ်ကူးများကို အကောင်အထည်ဖော်ရာတွင် မည်သည့်အခါမျှ ပြေလည်သွားခြင်းမရှိပေ။ ဤအတောအတွင်း၊ *DT ကုဒ်ကို အပိုင်းခွဲခွဲခြင်းသည် Eclipse တွင် မဖွံ့ဖြိုးသေးသော အကြောင်းအရာများထဲမှ တစ်ခု ဖြစ်နေဆဲဖြစ်သည်။

တစ်နည်းအားဖြင့် Handly ပရောဂျက်သည် EMF ကဲ့သို့ အနီးစပ်ဆုံး ပြဿနာများကို ဖြေရှင်းရန် ဒီဇိုင်းထုတ်ထားသော်လည်း ကိုင်တွယ်အခြေခံ မော်ဒယ်များနှင့် အဓိကအားဖြင့် ဘာသာစကားများ (ဆိုလိုသည်မှာ အချို့သော ပရိုဂရမ်းမင်းဘာသာစကား၏ ဖွဲ့စည်းပုံ၏ အစိတ်အပိုင်းများကို ကိုယ်စားပြုသည်)။ Handly ကို ဒီဇိုင်းဆွဲရာတွင် သတ်မှတ်ထားသော အဓိကပန်းတိုင်များကို အောက်တွင်ဖော်ပြထားပါသည်။

• ဘာသာရပ်နယ်ပယ်၏ အဓိကအနှစ်သာရများကို ဖော်ထုတ်ခြင်း။
• ကြိုးပမ်းအားထုတ်မှုကို လျှော့ချခြင်းနှင့် ကုဒ်ကို ပြန်လည်အသုံးပြုခြင်းဖြင့် ကိုင်တွယ်အခြေခံဘာသာစကားပုံစံများကို အကောင်အထည်ဖော်ခြင်း၏ အရည်အသွေးကို မြှင့်တင်ခြင်း။
• ရလဒ်မော်ဒယ်များသို့ စုစည်းထားသော မက်တာအဆင့် API ကို ပံ့ပိုးပေးခြင်းဖြင့် ဘာသာစကားကိုင်တွယ်မှုအခြေခံ မော်ဒယ်များနှင့် လုပ်ဆောင်နိုင်သော ဘုံ IDE အစိတ်အပိုင်းများကို ဖန်တီးနိုင်စေပါသည်။
• Flexibility နှင့် scalability ။
• Xtext နှင့် ပေါင်းစည်းခြင်း (သီးခြား အလွှာတစ်ခုတွင်)။

ဘုံအယူအဆများနှင့် ပရိုတိုကောများကို မီးမောင်းထိုးပြရန်၊ လက်ရှိအသုံးပြုနေသည့် ဘာသာစကားကိုင်တွယ်မှုပုံစံများကို ခွဲခြမ်းစိတ်ဖြာထားသည်။ Handly မှ ပံ့ပိုးပေးသော ပင်မအင်တာဖေ့စ်များနှင့် အခြေခံအကောင်အထည်ဖော်မှုများကို ပုံတွင် ပြထားသည်။ ၈။

ထမင်း။ 8. ဘုံအင်တာဖေ့စ်များနှင့် Handly ဒြပ်စင်များ၏ အခြေခံအကောင်အထည်ဖော်မှုများ

IElement အင်တာဖေ့စ်သည် ဒြပ်စင်တစ်ခု၏ လက်ကိုင်ကို ကိုယ်စားပြုပြီး Handly-based မော်ဒယ်များအားလုံး၏ ဒြပ်စင်များအတွက် အသုံးများသည်။ Abstract class Element သည် ယေဘူယျအားဖြင့် လက်ကိုင်/ကိုယ်ထည် ယန္တရားကို အကောင်အထည်ဖေါ်သည် (ပုံ။ ၉)။

ထမင်း။ 9. IElement နှင့် ယေဘူယျ လက်ကိုင်/ကိုယ်ထည် အကောင်အထည်ဖော်မှု

ထို့အပြင်၊ Handly သည် မော်ဒယ်ဒြပ်စင်များဆိုင်ရာ အပြောင်းအလဲများအကြောင်း အသိပေးရန်အတွက် ယေဘူယျအားဖြင့် ယန္တရားတစ်ခုကို ပံ့ပိုးပေးသည် (ပုံ။ ၁၀)။ သင်တွေ့မြင်ရသည့်အတိုင်း၊ ၎င်းသည် အရင်းအမြစ်မော်ဒယ်နှင့် Java မော်ဒယ်တွင် လုပ်ဆောင်ခဲ့သည့် အကြောင်းကြားချက်ယန္တရားများနှင့် ကျယ်ပြန့်စွာဆင်တူပြီး ဒြပ်စင်ပြောင်းလဲမှုအချက်အလက်ကို တစ်စုတစ်စည်းတည်းဖော်ပြရန် IElementDelta ကို အသုံးပြုသည်။

ထမင်း။ 10. အထွေထွေအင်တာဖေ့စ်များနှင့် Handly အသိပေးချက်ယန္တရား၏ အခြေခံအကောင်အထည်ဖော်မှုများ

အထက်တွင်ဖော်ပြထားသော Handly အပိုင်း (ပုံ။ 9 နှင့် 10) သည် လက်ကိုင်အခြေခံမော်ဒယ်များအားလုံးကို ကိုယ်စားပြုရန်အတွက် အသုံးပြုနိုင်သည်။ ဖန်တီးမှုအတွက် ဘာသာစကား မော်ဒယ်များ၊ ပရောဂျက်သည် အပိုလုပ်ဆောင်နိုင်စွမ်းကို ပေးဆောင်သည် - အထူးသဖြင့်၊ ဘုံအင်တာဖေ့စ်များနှင့် အရင်းအမြစ်စာသားဖွဲ့စည်းပုံ၏ ဒြပ်စင်များအတွက် အခြေခံအကောင်အထည်ဖော်မှုများ၊ အရင်းအမြစ်ဒြပ်စင်များ (ပုံ။ 8)။ ISourceFile အင်တာဖေ့စ်သည် အရင်းအမြစ်ဖိုင်ကို ကိုယ်စားပြုပြီး ISourceConstruct သည် အရင်းအမြစ်ဖိုင်အတွင်းမှ ဒြပ်စင်တစ်ခုကို ကိုယ်စားပြုသည်။ စိတ္တဇ အတန်းများသည် SourceFile နှင့် SourceConstruct တို့သည် အရင်းအမြစ်ဖိုင်များနှင့် ၎င်းတို့၏ဒြပ်စင်များနှင့် အလုပ်လုပ်ခြင်းကို ပံ့ပိုးရန် ယေဘူယျအားဖြင့် ယန္တရားများကို အကောင်အထည်ဖော်သည်၊ ဥပမာအားဖြင့်၊ စာသားကြားခံများဖြင့် လုပ်ဆောင်ခြင်း၊ အရင်းအမြစ်စာသားရှိ ဒြပ်စင်တစ်ခု၏ သြဒီနိတ်များနှင့် ပေါင်းစပ်ခြင်း၊ အလုပ်လုပ်နေသော ကော်ပီကြားခံ၏ လက်ရှိအကြောင်းအရာများနှင့် မော်ဒယ်များကို ပြန်လည်ပေါင်းစည်းခြင်း စသည်တို့ ဤယန္တရားများကို အကောင်အထည်ဖော်ခြင်းသည် များသောအားဖြင့် စိန်ခေါ်မှုတစ်ခုဖြစ်ပြီး Handly သည် အရည်အသွေးမြင့် အခြေခံအကောင်အထည်ဖော်မှုများကို ပံ့ပိုးပေးခြင်းဖြင့် ကိုင်တွယ်အခြေခံဘာသာစကားပုံစံများကို တီထွင်ထုတ်လုပ်ရန် ကြိုးစားအားထုတ်မှုကို သိသိသာသာ လျှော့ချနိုင်သည်။

အထက်ဖော်ပြပါ ပင်မယန္တရားများအပြင် Handly သည် စာသားကြားခံများနှင့် လျှပ်တစ်ပြက်ရိုက်ချက်များအတွက် အခြေခံအဆောက်အအုံတစ်ခု၊ အရင်းအမြစ်ကုဒ်တည်းဖြတ်သူများနှင့် ပေါင်းစည်းရန်အတွက် ပံ့ပိုးမှု (Xtext တည်းဖြတ်သူနှင့် ဘောက်စ်ပြင်ပတွင် ပေါင်းစည်းခြင်းအပါအဝင်) နှင့် အချို့သော ဘုံ UI အစိတ်အပိုင်းများ၊ အရင်းအမြစ်ကုဒ် တည်းဖြတ်သူများနှင့် လုပ်ဆောင်ပါ။ ကောက်ကြောင်းဘောင်ကဲ့သို့သော လက်ဖြင့် မော်ဒယ်များ။ ၎င်း၏စွမ်းဆောင်ရည်များကိုသရုပ်ဖော်ရန်၊ ပရောဂျက်သည် Handly တွင် Java မော်ဒယ်ကို အကောင်အထည်ဖော်မှုအပါအဝင် ဥပမာများစွာကို ပေးဆောင်သည်။ (JDT ရှိ Java မော်ဒယ်၏ အပြည့်အဝအကောင်အထည်ဖော်မှုနှင့် နှိုင်းယှဉ်ပါက၊ ဤမော်ဒယ်သည် ပိုမိုရှင်းလင်းပြတ်သားစေရန် ရည်ရွယ်၍ အနည်းငယ်ရိုးရှင်းပါသည်။)

အစောပိုင်းတွင်ဖော်ပြခဲ့သည့်အတိုင်း Handly ၏ကနဦးဒီဇိုင်းနှင့်နောက်ဆက်တွဲဖွံ့ဖြိုးတိုးတက်မှုအတွင်း အဓိကအာရုံစူးစိုက်မှုသည် အရွယ်အစားနှင့် လိုက်လျောညီထွေရှိမှုအပေါ် ဆက်လက်တည်ရှိနေပါသည်။

မူအရ၊ လက်ကိုင်အခြေခံမော်ဒယ်များသည် “ဒီဇိုင်းအားဖြင့်” ကောင်းစွာ အတိုင်းအတာရှိသည်။ ဥပမာအားဖြင့်၊ handle/body idiom သည် မော်ဒယ်တစ်ခုမှ သုံးစွဲသည့် memory ပမာဏကို ကန့်သတ်ရန် ခွင့်ပြုသည်။ ဒါပေမယ့်လည်း nuances တွေရှိပါတယ်။ ထို့ကြောင့်၊ Handly ကို အတိုင်းအတာအထိ စမ်းသပ်သည့်အခါ၊ အစိတ်အပိုင်းများစွာကို ပြောင်းလဲသောအခါ၊ deltas များကို တည်ဆောက်ရာတွင် အချိန်များစွာယူခဲ့ရသည့် အသိပေးချက်ယန္တရားကို အကောင်အထည်ဖော်ရာတွင် ပြဿနာတစ်ခု တွေ့ရှိခဲ့သည်။ တူညီသောပြဿနာသည် JDT Java မော်ဒယ်တွင် ရှိနေကြောင်း၊ သက်ဆိုင်ရာကုဒ်ကို တစ်ကြိမ်တည်းဖြင့် လိုက်လျောညီထွေဖြစ်စေသည်။ ကျွန်ုပ်တို့သည် Handly တွင် ချို့ယွင်းချက်ကို ပြင်ဆင်ပြီး ကျေးဇူးတင်စွာဖြင့် လက်ခံရရှိထားသည့် JDT အတွက် အလားတူ patch ကို ပြင်ဆင်ထားပါသည်။ ဤအခြေအနေတွင် တစ်နေရာတည်းတွင် ချွတ်ယွင်းချက်တစ်ခုကို ပြင်ဆင်နိုင်သောကြောင့် Handly ကို လက်ရှိပုံစံအကောင်အထည်ဖော်မှုများတွင် Handly မိတ်ဆက်ခြင်းသည် အသုံးဝင်နိုင်ချေရှိသည့် ဥပမာတစ်ခုသာဖြစ်သည်။

လက်ရှိပုံစံအကောင်အထည်ဖော်မှုများတွင် နည်းပညာအရ ဖြစ်နိုင်ခြေရှိသော Handly အကောင်အထည်ဖော်ရန်၊ စာကြည့်တိုက်သည် သိသာထင်ရှားသော လိုက်လျောညီထွေရှိရန် လိုအပ်ပါသည်။ အဓိကပြဿနာမှာ API မော်ဒယ်တစ်လျှောက် နောက်ပြန်လိုက်ဖက်မှုကို ထိန်းသိမ်းထားရန်ဖြစ်သည်။ ဒီပြဿနာကို ဖြေရှင်းနိုင်ခဲ့ပါတယ်။ Handly 0.5 စာကြည့်တိုက်မှ ပံ့ပိုးပေးထားသည့် စုစည်းထားသော meta-level API မှ developer မှ သတ်မှတ်ထားသော၊ အပြည့်အဝ ထိန်းချုပ်ထားသည့် မော်ဒယ်-သတ်မှတ် API ကို ရှင်းရှင်းလင်းလင်း ပိုင်းခြားထားသည်။ ၎င်းသည် လက်ရှိအကောင်အထည်ဖော်မှုများတွင် Handly ကို နည်းပညာပိုင်းအရ အကောင်အထည်ဖော်နိုင်စေရုံသာမက API ကို ဒီဇိုင်းရေးဆွဲသည့်အခါ မော်ဒယ်အသစ်တီထွင်သူအား သိသာထင်ရှားသောလွတ်လပ်ခွင့်များပေးသည်။

Flexibility မှာလည်း တခြားအချက်တွေရှိပါတယ်။ ဥပမာအားဖြင့်၊ Handly သည် မော်ဒယ်၏ဖွဲ့စည်းပုံအပေါ် ကန့်သတ်ချက်မရှိသလောက်ဖြစ်ပြီး ယေဘူယျရည်ရွယ်ချက်နှင့် ဒိုမိန်းအလိုက် ဘာသာစကားများကို စံနမူနာယူရန် အသုံးပြုနိုင်သည်။ အရင်းအမြစ်ဖိုင်၏ဖွဲ့စည်းပုံကိုတည်ဆောက်သောအခါ၊ Handly သည် AST ကိုယ်စားပြုမှုပုံစံကို အတိအကျမသတ်မှတ်ဘဲ၊ မူအရ AST ကိုယ်တိုင်ပါဝင်မှုပင်မလိုအပ်သောကြောင့် ခွဲခြမ်းစိတ်ဖြာမှုယန္တရားအားလုံးနီးပါးနှင့် လိုက်ဖက်မှုရှိစေရန် သေချာစေသည်။ နောက်ဆုံးအနေဖြင့် Handly သည် Eclipse workspace နှင့် အပြည့်အဝပေါင်းစပ်မှုကို ပံ့ပိုးပေးသည်၊ သို့သော် ၎င်းနှင့်ပေါင်းစပ်မှုကြောင့် ဖိုင်စနစ်များနှင့်လည်း တိုက်ရိုက်အလုပ်လုပ်နိုင်သည်။ Eclipse ဖိုင်စနစ် (တွတ်)။

လက်ရှိဗားရှင်း Handly 0.6 ဒီဇင်ဘာလ 2016 တွင်ထွက်ရှိခဲ့သည်။ ပရောဂျက်သည် လက်ရှိတွင်ပေါက်ဖွားနေသည့်အခြေအနေတွင်ရှိနေပြီး API ကိုနောက်ဆုံးတွင်မပြင်ဆင်ရသေးသော်လည်း၊ Handly သည် "အစောပိုင်းမွေးစားသူများ" အဖြစ်သရုပ်ဆောင်ရန်အန္တရာယ်ကိုယူထားသည့်ကြီးမားသောစီးပွားရေးထုတ်ကုန်နှစ်ခုတွင်အသုံးပြုထားပြီးဖြစ်သည်၊၊ ကျွန်ုပ်ပြောရပါမည်၊ နောင်တမရသေးဘူး။

အထက်တွင်ဖော်ပြခဲ့သည့်အတိုင်း၊ ဤထုတ်ကုန်များထဲမှတစ်ခုသည် 1C:Enterprise Development Tools ဖြစ်ပြီး၊ Handly ကိုအစကတည်းကအသုံးပြုသည့် 1C:Enterprise languages ​​၏အဆင့်မြင့်ဖွဲ့စည်းပုံတွင် ပါ၀င်သောပရိုဂရမ်းမင်းဘာသာစကားနှင့် query language အဖြစ်အသုံးပြုသော . နောက်တစ်ခုက လူသိနည်းတဲ့ ထုတ်ကုန်တစ်ခုပါ။ ဒီ Codasip စတူဒီယိုအက်ပလီကေးရှင်း-သက်ဆိုင်ရာ ညွှန်ကြားချက်-သတ်မှတ်ပရိုဆက်ဆာ (ASIP) အတွက် ပေါင်းစပ်ဒီဇိုင်းပတ်ဝန်းကျင်တစ်ခုဖြစ်သည့် ချက်နိုင်ငံ Codasip ကိုယ်တိုင်နှင့် ၎င်း၏ဖောက်သည်များအပါအဝင်၊ AMD ၏, AVG, မင်္ဂလာပါ, Sigma ဒီဇိုင်းများ. Codasip သည် Handly 2015 ဗားရှင်းဖြင့် စတင်ပြီး Handly ကို 0.2 ခုနှစ်ကတည်းက ထုတ်လုပ်ခဲ့သည်။ Codasip Studio ၏နောက်ဆုံးထွက်ရှိမှုသည် 0.5 ဇွန်လတွင်ထွက်ရှိထားသောဗားရှင်း 2016 ကိုအသုံးပြုထားသည်။ Codasip တွင် IDE ဖွံ့ဖြိုးတိုးတက်မှုကို ဦး ဆောင်သော Ondřej Ilčík သည် “တတိယပါတီလက်ခံသူ” ကိုယ်စား အရေးကြီးသော တုံ့ပြန်ချက်ပေးသည့် ပရောဂျက်နှင့် ဆက်သွယ်နေသည်။ Handly ဥပမာတစ်ခုဖြစ်သည့် Java မော်ဒယ်တစ်ခုအတွက် UI အလွှာ (ကုဒ်လိုင်းပေါင်း 4000 လိုင်း) ကို အကောင်အထည် ဖော်ခြင်းဖြင့် ပရောဂျက်၏ ဖွံ့ဖြိုးတိုးတက်မှုတွင် တိုက်ရိုက်ပါဝင်ရန် အားလပ်ချိန်အချို့ကိုပင် ရှာဖွေနိုင်ခဲ့သည်။ Handly by မွေးစားသူများ အသုံးပြုမှုနှင့် ပတ်သက်သော နောက်ထပ်အသေးစိတ်အချက်အလက်များကို စာမျက်နှာပေါ်တွင် တွေ့နိုင်ပါသည်။ အောင်မြင်မှုပုံပြင်များ ပရောဂျက်။

API တည်ငြိမ်မှုကို အာမခံချက်ဖြင့် ဗားရှင်း 1.0 နှင့် ပရောဂျက်မှ ပေါက်ဖွားမှုအခြေအနေမှ ထွက်ခွာပြီးနောက် Handly သည် လက်ခံသူအသစ်များရှိလာမည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ပါသည်။ ဤအတောအတွင်း၊ ပရောဂျက်သည် API ကို ဆက်လက်စမ်းသပ်ပြီး ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ကာ တစ်နှစ်လျှင် "အဓိက" ထုတ်ဝေမှု နှစ်ခုကို ဇွန်လ (တစ်ပြိုင်နက်နေကြတ်ခြင်းဖြန့်ချိသည့်ရက်စွဲအတိုင်း) နှင့် ဒီဇင်ဘာလတွင် စတင်ကာ မွေးစားသူများ အားကိုးနိုင်သည့် ကြိုတင်ခန့်မှန်းနိုင်သော အချိန်ဇယားကို ပေးဆောင်ပါသည်။ ပရောဂျက်၏ "ချွတ်ယွင်းမှုနှုန်း" သည် တစ်သမတ်တည်းနိမ့်ကျသောအဆင့်တွင် ရှိနေကြောင်းနှင့် Handly သည် ပထမဗားရှင်းများမှစ၍ အစောပိုင်းအသုံးပြုသူများ၏ ထုတ်ကုန်များတွင် ယုံကြည်စိတ်ချစွာ အလုပ်လုပ်နေကြောင်းလည်း ထည့်သွင်းနိုင်သည်။ Eclipse Handly ကို ထပ်မံစူးစမ်းရန်၊ သင်သုံးနိုင်သည်။ ကျူတိုရီရယ် စတင်ခြင်း။ и ဗိသုကာခြုံငုံသုံးသပ်ချက်.

source: www.habr.com