شاید، طویل عرصے سے کسی خاص تعارف کی ضرورت نہیں ہے۔ ایکلیپس جاوا ڈویلپمنٹ ٹولز کی بدولت بہت سے لوگ چاند گرہن سے واقف ہیں ()۔ یہ مقبول اوپن سورس جاوا IDE ہے جسے زیادہ تر ڈویلپر لفظ "Eclipse" کے ساتھ منسلک کرتے ہیں۔ تاہم، Eclipse دونوں ترقیاتی ٹولز (Eclipse Platform) کو مربوط کرنے کے لیے ایک قابل توسیع پلیٹ فارم ہے، اور اس کی بنیاد پر بنائے گئے متعدد IDEs، بشمول JDT۔ Eclipse دونوں ایکلیپس پروجیکٹ ہے، ایک اعلیٰ سطحی پروجیکٹ جو Eclipse پلیٹ فارم اور JDT کی ترقی کو مربوط کرتا ہے، اور Eclipse SDK، اس ترقی کا پیش کردہ نتیجہ۔ آخر میں، ایکلیپس ایک اوپن سورس فاؤنڈیشن ہے جس میں پروجیکٹس کی ایک بہت بڑی کمیونٹی ہے، جن میں سے سبھی جاوا میں نہیں لکھے گئے ہیں یا ترقیاتی ٹولز سے متعلق نہیں ہیں (مثال کے طور پر، پروجیکٹس и )۔ چاند گرہن کی دنیا بہت متنوع ہے۔
اس مضمون میں، جو کہ فطرت کا جائزہ ہے، ہم ایکلیپس کے فن تعمیر کی کچھ بنیادی باتوں کو مربوط ترقیاتی ٹولز بنانے کے پلیٹ فارم کے طور پر دیکھنے کی کوشش کریں گے اور ایکلیپس کے اجزاء کا ابتدائی خیال دیں گے جو ٹیکنالوجی کی بنیاد بناتے ہیں۔ "نیا کنفیگریٹر" 1C کے لیے پلیٹ فارم: انٹرپرائز۔ . بلاشبہ، اس طرح کا جائزہ ناگزیر طور پر بڑے پیمانے پر سطحی اور محدود ہوگا، بشمول اس لیے کہ ہم ہدف کے سامعین کے طور پر نہ صرف ایکلیپس ڈویلپرز پر توجہ مرکوز کر رہے ہیں۔ تاہم، ہم امید کرتے ہیں کہ ایکلیپس کے تجربہ کار ڈویلپر بھی مضمون میں دلچسپ معلومات حاصل کر سکیں گے۔ مثال کے طور پر، ہم "گرہن کے رازوں" میں سے ایک کے بارے میں بات کریں گے، جو ایک نسبتاً نیا اور بہت کم معروف پروجیکٹ ہے۔ ، جس کی بنیاد اور حمایت 1C نے کی تھی۔
ایکلیپس آرکیٹیکچر کا تعارف
آئیے پہلے مثال کا استعمال کرتے ہوئے چاند گرہن کے فن تعمیر کے کچھ عمومی پہلوؤں کو دیکھتے ہیں۔ (جے ڈی ٹی)۔ مثال کے طور پر JDT کا انتخاب حادثاتی نہیں ہے۔ یہ ایکلیپس میں ظاہر ہونے والا پہلا مربوط ترقیاتی ماحول ہے۔ دیگر *DT Eclipse پروجیکٹس، جیسے Eclipse C/C++ ڈویلپمنٹ ٹولنگ (CDT)، بعد میں بنائے گئے اور JDT سے بنیادی تعمیراتی اصولوں اور انفرادی سورس کوڈ کے ٹکڑے دونوں ادھار لیے گئے۔ JDT میں دیے گئے فن تعمیر کے بنیادی اصول ایکلیپس پلیٹ فارم کے اوپر بنے ہوئے تقریباً کسی بھی IDE کے لیے آج تک متعلقہ ہیں، بشمول 1C:Enterprise Development Tools۔
سب سے پہلے، یہ غور کرنا چاہیے کہ چاند گرہن کی خاصیت کافی واضح آرکیٹیکچرل لیئرنگ سے ہوتی ہے، جس میں مخصوص پروگرامنگ زبانوں کو سپورٹ کرنے کے لیے بنائے گئے فنکشنلٹی سے زبان سے آزاد فعالیت کی علیحدگی، اور UI سے آزاد "بنیادی" اجزاء کو منسلک اجزاء سے الگ کرنا۔ معاون صارف انٹرفیس کے ساتھ۔
اس طرح، ایکلیپس پلیٹ فارم ایک عام، زبان سے آزاد انفراسٹرکچر کی وضاحت کرتا ہے، اور جاوا ڈیولپمنٹ ٹولز ایک مکمل خصوصیات والے جاوا IDE کو Eclipse میں شامل کرتے ہیں۔ ایکلیپس پلیٹ فارم اور JDT دونوں کئی اجزاء پر مشتمل ہیں، جن میں سے ہر ایک UI سے آزاد "کور" یا UI پرت سے تعلق رکھتا ہے (شکل 1)۔
چاول۔ 1. ایکلیپس پلیٹ فارم اور JDT
آئیے ایکلیپس پلیٹ فارم کے اہم اجزاء کی فہرست بناتے ہیں:
- رن ٹائم - پلگ ان کے بنیادی ڈھانچے کی وضاحت کرتا ہے۔ چاند گرہن ایک ماڈیولر فن تعمیر کی خصوصیت ہے۔ بنیادی طور پر، چاند گرہن "ایکسٹینشن پوائنٹس" اور "ایکسٹینشنز" کا مجموعہ ہے۔
- ورک اسپیس - ایک یا زیادہ پروجیکٹس کا انتظام کرتا ہے۔ ایک پروجیکٹ فولڈرز اور فائلوں پر مشتمل ہوتا ہے جو براہ راست فائل سسٹم میں میپ ہوتے ہیں۔
- معیاری ویجیٹ ٹول کٹ (SWT) - آپریٹنگ سسٹم کے ساتھ مربوط بنیادی صارف انٹرفیس عناصر فراہم کرتا ہے۔
- جے فیس - SWT کے اوپر بنائے گئے متعدد UI فریم ورک فراہم کرتا ہے۔
- ورک بینچ - Eclipse UI پیراڈیم کی وضاحت کرتا ہے: ایڈیٹرز، آراء، تناظر۔
یہ کہنا ضروری ہے کہ Eclipse پلیٹ فارم ڈیبگ، موازنہ، تلاش اور ٹیم سمیت مربوط ترقیاتی ٹولز بنانے کے لیے بہت سے دوسرے مفید اجزاء بھی فراہم کرتا ہے۔ JFace Text کا خصوصی تذکرہ کیا جانا چاہیے - ماخذ کوڈ کے "سمارٹ ایڈیٹرز" بنانے کی بنیاد۔ بدقسمتی سے، اس مضمون کے دائرہ کار میں ان اجزاء کے ساتھ ساتھ UI پرت کے اجزاء کی بھی سرسری جانچ ممکن نہیں ہے، لہٰذا اس حصے کے بقیہ حصے میں ہم خود کو اس مضمون کے اہم "بنیادی" اجزاء کے جائزہ تک محدود رکھیں گے۔ ایکلیپس پلیٹ فارم اور جے ڈی ٹی۔
کور رن ٹائم
ایکلیپس پلگ ان انفراسٹرکچر پر مبنی ہے۔ اور پروجیکٹ کے ذریعہ فراہم کیا گیا ہے۔ . ہر ایکلیپس پلگ ان ایک OSGi بنڈل ہے۔ OSGi تصریح، خاص طور پر، ورژن بنانے اور انحصار کے حل کے طریقہ کار کی وضاحت کرتی ہے۔ ان معیاری میکانزم کے علاوہ، Equinox تصور کو متعارف کراتا ہے۔ توسیع پوائنٹس. ہر پلگ ان اپنے ایکسٹینشن پوائنٹس کی وضاحت کر سکتا ہے، اور اسی یا دوسرے پلگ انز کے ذریعے بیان کردہ ایکسٹینشن پوائنٹس کا استعمال کرتے ہوئے سسٹم میں اضافی فعالیت ("ایکسٹینشن") بھی متعارف کرا سکتا ہے۔ OSGi اور Equinox میکانزم کی کوئی بھی تفصیلی وضاحت اس مضمون کے دائرہ کار سے باہر ہے۔ آئیے صرف نوٹ کریں کہ چاند گرہن میں ماڈیولرائزیشن کل ہے (کوئی بھی سب سسٹم، بشمول رن ٹائم، ایک یا زیادہ پلگ ان پر مشتمل ہوتا ہے)، اور چاند گرہن میں تقریباً ہر چیز ایک توسیع ہے۔ مزید یہ کہ، یہ اصول او ایس جی آئی کے متعارف ہونے سے بہت پہلے ایکلیپس فن تعمیر میں سرایت کر گئے تھے (اس وقت انہوں نے اپنی ٹیکنالوجی کا استعمال کیا تھا، جو کہ او ایس جی آئی سے ملتا جلتا تھا)۔
کور ورک اسپیس
Eclipse پلیٹ فارم کے اوپر بنایا ہوا تقریباً کوئی بھی مربوط ترقیاتی ماحول Eclipse ورک اسپیس کے ساتھ کام کرتا ہے۔ یہ وہ ورک اسپیس ہے جس میں عام طور پر IDE میں تیار کردہ ایپلیکیشن کا سورس کوڈ ہوتا ہے۔ ورک اسپیس کا نقشہ براہ راست فائل سسٹم پر ہوتا ہے اور اس میں ایسے پروجیکٹ ہوتے ہیں جن میں فولڈرز اور فائلیں ہوتی ہیں۔ ان منصوبوں، فولڈرز، اور فائلوں کو کہا جاتا ہے حوالہ جات کام کی جگہ Eclipse میں ورک اسپیس کا نفاذ فائل سسٹم کے سلسلے میں ایک کیشے کا کام کرتا ہے، جس کی وجہ سے وسائل کے درخت کو عبور کرنے کی رفتار کو نمایاں طور پر تیز کرنا ممکن ہوتا ہے۔ اس کے علاوہ، ورک اسپیس متعدد اضافی خدمات فراہم کرتا ہے، بشمول и .
بنیادی وسائل کا جزو (org.eclipse.core.resources پلگ ان) ورک اسپیس اور اس کے وسائل کو سپورٹ کرنے کا ذمہ دار ہے۔ خاص طور پر، یہ جزو فارم میں ورک اسپیس تک پروگرامیٹک رسائی فراہم کرتا ہے۔ وسائل کے ماڈل. اس ماڈل کے ساتھ مؤثر طریقے سے کام کرنے کے لیے، کلائنٹس کو وسائل کا لنک پیش کرنے کے لیے ایک آسان طریقہ کی ضرورت ہے۔ اس صورت میں، اس چیز کو چھپانا ضروری ہوگا جو کلائنٹ کی رسائی سے ماڈل میں وسائل کی حالت کو براہ راست اسٹور کرتا ہے۔ دوسری صورت میں، مثال کے طور پر، کسی فائل کو حذف کرنے کی صورت میں، کلائنٹ اس چیز کو برقرار رکھ سکتا ہے جو اب ماڈل میں نہیں ہے، آنے والے مسائل کے ساتھ۔ Eclipse نامی چیز کا استعمال کرتے ہوئے اس مسئلے کو حل کرتا ہے۔ ہینڈل وسائل ہینڈل ایک کلید کے طور پر کام کرتا ہے (یہ صرف ورک اسپیس میں وسائل کا راستہ جانتا ہے) اور اندرونی ماڈل آبجیکٹ تک رسائی کو مکمل طور پر کنٹرول کرتا ہے، جو وسائل کی حالت کے بارے میں معلومات کو براہ راست ذخیرہ کرتا ہے۔ یہ ڈیزائن پیٹرن کی تبدیلی ہے۔ .
چاول۔ شکل 2 ہینڈل/باڈی کے محاورے کی وضاحت کرتا ہے جیسا کہ وسائل کے ماڈل پر لاگو ہوتا ہے۔ IRsource انٹرفیس وسائل کے ہینڈل کی نمائندگی کرتا ہے اور ایک API ہے، وسائل کلاس کے برعکس، جو اس انٹرفیس کو نافذ کرتا ہے، اور ResourceInfo کلاس، جو جسم کی نمائندگی کرتا ہے، جو APIs نہیں ہیں۔ ہم اس بات پر زور دیتے ہیں کہ ہینڈل صرف ورک اسپیس روٹ سے متعلق وسائل کا راستہ جانتا ہے اور اس میں وسائل کی معلومات کا لنک نہیں ہے۔ وسائل کی معلومات اشیاء ایک نام نہاد "عنصر درخت" تشکیل دیتے ہیں. یہ ڈیٹا ڈھانچہ میموری میں مکمل طور پر مادی ہے۔ کسی ہینڈل سے متعلق وسائل کی معلومات کی مثال تلاش کرنے کے لیے، عنصر کے درخت کو اس ہینڈل میں محفوظ کردہ راستے کے مطابق عبور کیا جاتا ہے۔
چاول۔ 2. IRsource اور ResourceInfo
جیسا کہ ہم بعد میں دیکھیں گے، ریسورس ماڈل کا بنیادی ڈیزائن (ہم اسے ہینڈل پر مبنی کہہ سکتے ہیں) دوسرے ماڈلز کے لیے بھی Eclipse میں استعمال ہوتا ہے۔ ابھی کے لیے، آئیے اس ڈیزائن کی کچھ مخصوص خصوصیات کی فہرست بناتے ہیں:
- ہینڈل ایک ویلیو آبجیکٹ ہے۔ ویلیو آبجیکٹ ناقابل تغیر اشیاء ہیں جن کی مساوات شناخت پر مبنی نہیں ہے۔ ایسی اشیاء کو ہیشڈ کنٹینرز میں کلید کے طور پر محفوظ طریقے سے استعمال کیا جا سکتا ہے۔ ہینڈل کی متعدد مثالیں ایک ہی وسائل کا حوالہ دے سکتی ہیں۔ ان کا موازنہ کرنے کے لیے، آپ کو equals(Object) طریقہ استعمال کرنے کی ضرورت ہے۔
- ہینڈل وسائل کے رویے کی وضاحت کرتا ہے، لیکن وسائل کی حالت کے بارے میں معلومات پر مشتمل نہیں ہوتا ہے (صرف ڈیٹا جو اسے اسٹور کرتا ہے وہ "کلید" ہے، وسائل کا راستہ)۔
- ہینڈل کسی ایسے وسائل کا حوالہ دے سکتا ہے جو موجود نہیں ہے (یا تو ایسا وسیلہ جو ابھی تک نہیں بنایا گیا ہے، یا ایسا وسیلہ جو پہلے ہی حذف ہوچکا ہے)۔ وسائل کے وجود کو IRsource.exists() طریقہ استعمال کرکے چیک کیا جا سکتا ہے۔
- کچھ آپریشنز کو مکمل طور پر ہینڈل میں محفوظ کردہ معلومات کی بنیاد پر لاگو کیا جا سکتا ہے (نام نہاد ہینڈل صرف آپریشنز)۔ مثالیں ہیں IResource.getParent(), getFullPath(), وغیرہ۔ اس طرح کے آپریشن کی کامیابی کے لیے وسائل کا موجود ہونا ضروری نہیں ہے۔ ایسی کارروائیاں جن کے لیے کامیابی کے لیے وسائل کی ضرورت ہوتی ہے اگر وسیلہ موجود نہ ہو تو CoreException پھینک دیں۔
Eclipse ورک اسپیس وسائل کی تبدیلیوں کو مطلع کرنے کے لیے ایک موثر طریقہ کار فراہم کرتا ہے (شکل 3)۔ وسائل یا تو خود Eclipse IDE کے اندر انجام پانے والے اعمال کے نتیجے میں یا فائل سسٹم کے ساتھ مطابقت پذیری کے نتیجے میں تبدیل ہو سکتے ہیں۔ دونوں صورتوں میں، کلائنٹس جو نوٹیفیکیشنز کو سبسکرائب کرتے ہیں انہیں "ریسورس ڈیلٹا" کی شکل میں ہونے والی تبدیلیوں کے بارے میں تفصیلی معلومات فراہم کی جاتی ہیں۔ ڈیلٹا ورک اسپیس ریسورس (سب) درخت کی دو حالتوں کے درمیان تبدیلیوں کو بیان کرتا ہے اور خود ایک درخت ہے، جس میں سے ہر نوڈ وسائل میں ہونے والی تبدیلی کو بیان کرتا ہے اور اگلی سطح پر ڈیلٹا کی فہرست پر مشتمل ہوتا ہے جو بچوں کے وسائل میں ہونے والی تبدیلیوں کو بیان کرتا ہے۔
چاول۔ 3. IResourceChangeEvent اور IResourceDelta
ریسورس ڈیلٹا پر مبنی نوٹیفکیشن میکانزم میں درج ذیل خصوصیات ہیں:
- ایک ہی تبدیلی اور بہت سی تبدیلیوں کو ایک ہی ڈھانچے کا استعمال کرتے ہوئے بیان کیا گیا ہے، کیونکہ ڈیلٹا ریکسریو کمپوزیشن کے اصول کو استعمال کرتے ہوئے بنایا گیا ہے۔ سبسکرائبر کلائنٹس ڈیلٹا کے درخت کے ذریعے ریکورسیو ڈیسنٹ کا استعمال کرتے ہوئے وسائل کی تبدیلی کی اطلاعات پر کارروائی کر سکتے ہیں۔
- ڈیلٹا وسائل میں ہونے والی تبدیلیوں کے بارے میں مکمل معلومات پر مشتمل ہے، بشمول اس کی نقل و حرکت اور/یا اس سے وابستہ "مارکرز" میں تبدیلیاں (مثال کے طور پر، تالیف کی غلطیاں بطور مارکر ظاہر کی جاتی ہیں)۔
- چونکہ وسائل کے حوالہ جات ہینڈل کے ذریعے بنائے جاتے ہیں، ڈیلٹا قدرتی طور پر دور دراز کے وسائل کا حوالہ دے سکتا ہے۔
جیسا کہ ہم جلد ہی دیکھیں گے، وسائل کے ماڈل کی تبدیلی کے نوٹیفکیشن میکانزم کے ڈیزائن کے اہم اجزاء دوسرے ہینڈل پر مبنی ماڈلز کے لیے بھی متعلقہ ہیں۔
جے ڈی ٹی کور
Eclipse ورک اسپیس ریسورس ماڈل ایک بنیادی زبان کا اگنوسٹک ماڈل ہے۔ جے ڈی ٹی کور جزو (پلگ ان org.eclipse.jdt.core) جاوا کے نقطہ نظر سے ورک اسپیس کے ڈھانچے کو نیویگیٹ کرنے اور تجزیہ کرنے کے لیے ایک API فراہم کرتا ہے، نام نہاد "جاوا ماڈل" (جاوا ماڈل)۔ اس API کی وضاحت جاوا عناصر کے لحاظ سے کی گئی ہے، جیسا کہ بنیادی وسائل کے ماڈل API کے برخلاف، جس کی وضاحت فولڈرز اور فائلوں کے لحاظ سے کی گئی ہے۔ جاوا عنصر کے درخت کے مرکزی انٹرفیس تصویر میں دکھائے گئے ہیں۔ 4.
چاول۔ 4. جاوا ماڈل عناصر
جاوا ماڈل وہی ہینڈل/باڈی محاورہ استعمال کرتا ہے جیسا کہ ریسورس ماڈل (شکل 5)۔ IJavaElement ہینڈل ہے، اور JavaElementInfo باڈی کا کردار ادا کرتا ہے۔ IJavaElement انٹرفیس تمام جاوا عناصر کے لیے مشترکہ پروٹوکول کی وضاحت کرتا ہے۔ اس کے کچھ طریقے صرف ہینڈل ہیں: getElementName(), getParent(), وغیرہ۔ JavaElementInfo آبجیکٹ متعلقہ عنصر کی حالت کو ذخیرہ کرتا ہے: اس کی ساخت اور صفات۔
چاول۔ 5. IJavaElement اور JavaElementInfo
جاوا ماڈل میں وسائل کے ماڈل کے مقابلے میں بنیادی ہینڈل/باڈی ڈیزائن کے نفاذ میں کچھ اختلافات ہیں۔ جیسا کہ اوپر بیان کیا گیا ہے، ریسورس ماڈل میں، عنصر کا درخت، جس کے نوڈس وسائل کی معلومات کی اشیاء ہیں، مکمل طور پر میموری میں موجود ہے۔ لیکن جاوا ماڈل میں وسائل کے درخت کے مقابلے عناصر کی نمایاں طور پر بڑی تعداد ہو سکتی ہے، کیونکہ یہ .java اور .class فائلوں کی اندرونی ساخت کی بھی نمائندگی کرتا ہے: اقسام، فیلڈز اور طریقے۔
میموری میں عناصر کے پورے درخت کو مکمل طور پر بنانے سے بچنے کے لیے، جاوا ماڈل کا نفاذ عنصر کی معلومات کے محدود سائز کے LRU کیش کا استعمال کرتا ہے، جہاں کلید ہینڈل IJavaElement ہے۔ عنصر کی معلومات کے آبجیکٹ ڈیمانڈ پر بنائے جاتے ہیں کیونکہ عنصر کے درخت کو نیویگیٹ کیا جاتا ہے۔ اس صورت میں، کم سے کم اکثر استعمال ہونے والی اشیاء کو کیشے سے نکال دیا جاتا ہے، اور ماڈل کی میموری کی کھپت مخصوص کیشے کے سائز تک محدود رہتی ہے۔ یہ ہینڈل پر مبنی ڈیزائن کا ایک اور فائدہ ہے، جو کلائنٹ کوڈ سے اس طرح کے نفاذ کی تفصیلات کو مکمل طور پر چھپاتا ہے۔
جاوا عناصر میں تبدیلیوں کو مطلع کرنے کا طریقہ کار عمومی طور پر اوپر زیر بحث ورک اسپیس وسائل میں تبدیلیوں کو ٹریک کرنے کے طریقہ کار سے ملتا جلتا ہے۔ ایک کلائنٹ جو جاوا ماڈل میں تبدیلیوں کی نگرانی کرنا چاہتا ہے نوٹیفیکیشنز کو سبسکرائب کرتا ہے، جس کی نمائندگی ایک ElementChangedEvent آبجیکٹ کے طور پر کی جاتی ہے جس میں IJavaElementDelta (شکل 6) ہوتا ہے۔
چاول۔ 6. ElementChangedEvent اور IJavaElementDelta
جاوا ماڈل میتھڈ باڈیز یا نام کے حل کے بارے میں معلومات پر مشتمل نہیں ہے، لہذا جاوا میں لکھے گئے کوڈ کے تفصیلی تجزیہ کے لیے، JDT Core ایک اضافی (نان ہینڈل پر مبنی) ماڈل فراہم کرتا ہے: (خلاصہ نحوی درخت، AST) AST سورس ٹیکسٹ کو پارس کرنے کے نتیجے کی نمائندگی کرتا ہے۔ AST نوڈس ماخذ ماڈیول کی ساخت کے عناصر سے مطابقت رکھتے ہیں (اعلانات، آپریٹرز، اظہار، وغیرہ) اور ماخذ متن میں متعلقہ عنصر کے نقاط کے بارے میں معلومات کے ساتھ ساتھ (ایک اختیار کے طور پر) میں نام کے حل کے بارے میں معلومات پر مشتمل ہے۔ نام نہاد کے لنکس کی شکل بینڈنگ. بائنڈنگز ایسی اشیاء ہیں جو نامزد اداروں کی نمائندگی کرتی ہیں، جیسے کہ اقسام، طریقے، اور متغیرات، جو مرتب کرنے والے کو معلوم ہیں۔ AST نوڈس کے برعکس، جو ایک درخت بناتے ہیں، بائنڈنگس کراس ریفرنسنگ کو سپورٹ کرتی ہیں اور عام طور پر ایک گراف بناتی ہیں۔ خلاصہ کلاس ASTNode تمام AST نوڈس کے لئے مشترکہ بیس کلاس ہے۔ ASTNode ذیلی طبقات جاوا زبان کی مخصوص نحوی تعمیرات سے مطابقت رکھتے ہیں۔
چونکہ نحوی درخت کافی مقدار میں میموری استعمال کر سکتے ہیں، اس لیے JDT فعال ایڈیٹر کے لیے صرف ایک AST کیش کرتا ہے۔ جاوا ماڈل کے برعکس، AST کو عام طور پر ایک "انٹرمیڈیٹ،" "عارضی" ماڈل کے طور پر دیکھا جاتا ہے جس کے اراکین کو کلائنٹس کے ذریعہ آپریشن کے سیاق و سباق سے باہر حوالہ نہیں دیا جانا چاہئے جس کی وجہ سے AST کی تخلیق ہوئی۔
درج کردہ تین ماڈلز (جاوا ماڈل، اے ایس ٹی، بائنڈنگز) مل کر جے ڈی ٹی میں "ذہین ترقیاتی ٹولز" بنانے کی بنیاد بناتے ہیں، جس میں مختلف "مددگاروں" کے ساتھ ایک طاقتور جاوا ایڈیٹر، سورس کوڈ پر کارروائی کے لیے مختلف اقدامات شامل ہیں (درآمد کی فہرست کو ترتیب دینا بھی شامل ہے۔ اپنی مرضی کے مطابق طرز کے مطابق نام اور فارمیٹنگ)، تلاش اور ریفیکٹرنگ ٹولز۔ اس معاملے میں، جاوا ماڈل ایک خاص کردار ادا کرتا ہے، کیونکہ یہ وہی ہے جسے ایپلیکیشن کی ساخت کی بصری نمائندگی کے لیے بنیاد کے طور پر استعمال کیا جاتا ہے (مثال کے طور پر، پیکیج ایکسپلورر، آؤٹ لائن، تلاش، کال کے درجہ بندی، اور درجہ بندی کی قسم)۔
1C میں استعمال ہونے والے چاند گرہن کے اجزاء: انٹرپرائز ڈویلپمنٹ ٹولز
تصویر میں شکل 7 چاند گرہن کے اجزاء کو دکھاتا ہے جو 1C: انٹرپرائز ڈویلپمنٹ ٹولز کے ٹیکنالوجی پلیٹ فارم کی بنیاد بناتے ہیں۔
چاول۔ 7. 1C کے لیے ایک پلیٹ فارم کے طور پر چاند گرہن: انٹرپرائز ڈویلپمنٹ ٹولز
چاند گرہن کا پلیٹ فارم بنیادی ڈھانچہ فراہم کرتا ہے۔ ہم نے پچھلے حصے میں اس بنیادی ڈھانچے کے کچھ پہلوؤں کو دیکھا۔
(EMF) سٹرکچرڈ ڈیٹا کی ماڈلنگ کا ایک عام ذریعہ فراہم کرتا ہے۔ EMF Eclipse پلیٹ فارم کے ساتھ مربوط ہے، لیکن اسے باقاعدہ Java ایپلیکیشنز میں الگ سے بھی استعمال کیا جا سکتا ہے۔ اکثر، نئے Eclipse ڈویلپرز پہلے سے ہی EMF سے اچھی طرح واقف ہوتے ہیں، حالانکہ وہ ابھی تک Eclipse پلیٹ فارم کی پیچیدگیوں کو پوری طرح سے نہیں سمجھتے ہیں۔ اس قدر مستحق مقبولیت کی ایک وجہ عالمگیر ڈیزائن ہے، جس میں دیگر چیزوں کے علاوہ، ایک متحد میٹا لیول API بھی شامل ہے، جو آپ کو کسی بھی EMF ماڈل کے ساتھ عمومی طور پر کام کرنے کی اجازت دیتا ہے۔ EMF کی طرف سے فراہم کردہ ماڈل آبجیکٹ کے لیے بنیادی نفاذ اور میٹا ماڈل پر مبنی ماڈل کوڈ بنانے کے لیے ذیلی نظام ترقی کی رفتار کو نمایاں طور پر بڑھاتے ہیں اور غلطیوں کی تعداد کو کم کرتے ہیں۔ EMF میں ماڈلز کو سیریلائز کرنے، ماڈل میں تبدیلیوں سے باخبر رہنے اور بہت کچھ کرنے کا طریقہ کار بھی شامل ہے۔
کسی بھی صحیح معنوں میں عام مقصد والے ٹول کی طرح، EMF ماڈلنگ کے مسائل کی ایک وسیع رینج کو حل کرنے کے لیے موزوں ہے، لیکن ماڈل کی کچھ کلاسز (مثال کے طور پر، ہینڈل پر مبنی ماڈلز جن پر اوپر بحث کی گئی ہے) کو زیادہ خصوصی ماڈلنگ ٹولز کی ضرورت ہو سکتی ہے۔ EMF کے بارے میں بات کرنا ایک ناشکری کا کام ہے، خاص طور پر ایک مضمون کی محدود حدود میں، کیونکہ یہ ایک الگ کتاب کا موضوع ہے، بلکہ ایک موٹی کتاب ہے۔ آئیے صرف اس بات کو نوٹ کریں کہ EMF کے تحت عام کرنے کے اعلیٰ معیار کے نظام نے ماڈلنگ کے لیے وقف منصوبوں کی ایک پوری رینج کو جنم دینے کی اجازت دی، جو اعلیٰ سطح کے پروجیکٹ میں شامل ہیں۔ خود EMF کے ساتھ۔ ایسا ہی ایک پروجیکٹ Eclipse Xtext ہے۔
ایک "ٹیکسٹ ماڈلنگ" کا بنیادی ڈھانچہ فراہم کرتا ہے۔ Xtext استعمال کرتا ہے۔ نتیجے میں آنے والے ASG کی نمائندگی کرنے کے لیے سورس ٹیکسٹ اور EMF کو پارس کرنے کے لیے (خلاصہ سیمینٹک گراف، جو بنیادی طور پر AST اور بائنڈنگز کا مجموعہ ہے)، جسے "Semantic model" بھی کہا جاتا ہے۔ Xtext کے ذریعہ وضع کردہ زبان کا گرامر Xtext کی اپنی زبان میں بیان کیا گیا ہے۔ یہ آپ کو نہ صرف ANTLR کے لیے گرائمر کی وضاحت تیار کرنے کی اجازت دیتا ہے، بلکہ AST سیریلائزیشن میکانزم (یعنی Xtext ایک پارسر اور ایک غیر پارسر دونوں فراہم کرتا ہے)، ایک سیاق و سباق کا اشارہ، اور زبان کے متعدد دیگر اجزاء حاصل کرنے کی بھی اجازت دیتا ہے۔ دوسری طرف، Xtext میں استعمال ہونے والی گرامر کی زبان ANTLR میں استعمال ہونے والی گرامر زبان کے مقابلے میں کم لچکدار ہے۔ لہذا، بعض اوقات نافذ شدہ زبان کو Xtext کی طرف "مڑنا" ضروری ہوتا ہے، جو عام طور پر کوئی مسئلہ نہیں ہے اگر ہم شروع سے تیار ہونے والی زبان کے بارے میں بات کر رہے ہیں، لیکن پہلے سے قائم شدہ نحو والی زبانوں کے لیے ناقابل قبول ہو سکتا ہے۔ اس کے باوجود، ایکس ٹیکسٹ فی الحال ایکلیپس میں پروگرامنگ زبانوں اور ان کے لیے ڈویلپمنٹ ٹولز بنانے کے لیے سب سے زیادہ پختہ، خصوصیت سے بھرپور اور ورسٹائل ٹول ہے۔ خاص طور پر، یہ تیز رفتار پروٹو ٹائپنگ کے لیے ایک مثالی ٹول ہے۔ (ڈومین کے لیے مخصوص زبان، DSL)۔ ANTLR اور EMF پر مبنی اوپر بیان کردہ "لینگویج کور" کے علاوہ، Xtext بہت سے مفید اعلیٰ سطحی اجزاء فراہم کرتا ہے، بشمول اشاریہ سازی کا طریقہ کار، انکریمنٹل کنسٹرکشن، ایک "سمارٹ ایڈیٹر"، اور بہت کچھ، لیکن ہینڈل چھوڑ دیتا ہے۔ زبان کے ماڈلز پر مبنی۔ EMF کی طرح، Xtext ایک الگ کتاب کے لائق ایک موضوع ہے، اور ہم ابھی اس کی تمام صلاحیتوں کے بارے میں شاید ہی مختصر طور پر بات کر سکتے ہیں۔
1C: انٹرپرائز ڈویلپمنٹ ٹولز خود EMF اور دیگر ایکلیپس ماڈلنگ پروجیکٹس دونوں کو فعال طور پر استعمال کرتے ہیں۔ خاص طور پر، Xtext ایسے 1C کے لیے ترقیاتی ٹولز کی بنیادوں میں سے ایک ہے: انٹرپرائز لینگوئجز بطور بلٹ ان پروگرامنگ لینگویج اور استفسار کی زبان۔ ان ڈویلپمنٹ ٹولز کی ایک اور بنیاد ایکلیپس ہینڈلی پروجیکٹ ہے، جس پر ہم مزید تفصیل سے بات کریں گے (درج کردہ ایکلیپس اجزاء میں سے، یہ ابھی تک سب سے کم معلوم ہے)۔
1 میں 2014C کے ذریعے Eclipse فاؤنڈیشن میں ابتدائی کوڈ شراکت کے نتیجے میں Eclipse ٹیکنالوجی کے اعلیٰ سطحی منصوبے کا ایک ذیلی پروجیکٹ سامنے آیا۔ اس کے بعد سے، 1C نے اس منصوبے کی ترقی کی حمایت جاری رکھی ہے: ہینڈلی کمٹٹرز کمپنی کے ملازم ہیں۔ پروجیکٹ چھوٹا ہے، لیکن یہ چاند گرہن میں ایک منفرد مقام رکھتا ہے: اس کا بنیادی مقصد ہینڈل پر مبنی ماڈلز کی ترقی میں مدد کرنا ہے۔
ہینڈل پر مبنی ماڈلز کے بنیادی تعمیراتی اصول، جیسے کہ ہینڈل/باڈی محاورہ، وسائل کے ماڈل اور جاوا ماڈل کو بطور مثال استعمال کرتے ہوئے اوپر زیر بحث آئے۔ اس نے یہ بھی نوٹ کیا کہ ریسورس ماڈل اور جاوا ماڈل دونوں ایکلیپس جاوا ڈویلپمنٹ ٹولز (JDT) کے لیے اہم بنیادیں ہیں۔ اور چونکہ تقریباً تمام *DT Eclipse پروجیکٹس کا ایک فن تعمیر JDT سے ملتا جلتا ہے، اس لیے یہ کہنا بہت زیادہ مبالغہ آرائی نہیں ہوگا کہ ہینڈل پر مبنی ماڈلز بہت سے زیر اثر ہیں، اگر تمام IDEs Eclipse پلیٹ فارم کے اوپر نہیں بنائے گئے ہیں۔ مثال کے طور پر، Eclipse C/C++ ڈویلپمنٹ ٹولنگ (CDT) میں ہینڈل پر مبنی C/C++ ماڈل ہے جو CDT فن تعمیر میں وہی کردار ادا کرتا ہے جیسا کہ جاوا ماڈل JDT میں کرتا ہے۔
Handly سے پہلے، Eclipse نے ہینڈل پر مبنی زبان کے ماڈل بنانے کے لیے خصوصی لائبریریاں پیش نہیں کی تھیں۔ جو ماڈل فی الحال موجود ہیں وہ بنیادی طور پر جاوا ماڈل کوڈ (عرف کاپی/پیسٹ) کو براہ راست ڈھال کر بنائے گئے تھے۔ ان صورتوں میں جہاں یہ اجازت دیتا ہے۔ ایکلیپس پبلک لائسنس (ای پی ایل)۔ (ظاہر ہے، یہ عام طور پر ایکلیپس پروجیکٹس کے لیے کوئی قانونی مسئلہ نہیں ہے، لیکن بند سورس پروڈکٹس کے لیے نہیں۔) اپنی موروثی بے ترتیبی کے علاوہ، یہ تکنیک معروف مسائل کو متعارف کراتی ہے: کوڈ کی نقل متعارف کرائی گئی جب غلطیوں کو اپناتے ہوئے، وغیرہ سب سے بری بات یہ ہے کہ نتیجے میں آنے والے ماڈلز "خود میں چیزیں" ہی رہتے ہیں اور اتحاد کے امکانات سے فائدہ نہیں اٹھاتے۔ لیکن ہینڈل پر مبنی لینگویج ماڈلز کے لیے عام تصورات اور پروٹوکولز کو الگ کرنا ان کے ساتھ کام کرنے کے لیے دوبارہ قابل استعمال اجزاء کی تخلیق کا باعث بن سکتا ہے، جیسا کہ EMF کے معاملے میں ہوا تھا۔
ایسا نہیں ہے کہ چاند گرہن کو ان مسائل کی سمجھ نہیں آئی۔ واپس 2005 میں سی ڈی ٹی پروٹو ٹائپ تیار کرنے کے تجربے کا خلاصہ، زبان کے ماڈلز کے لیے ایک مشترکہ انفراسٹرکچر بنانے کی ضرورت، بشمول ہینڈل پر مبنی ماڈلز۔ لیکن، جیسا کہ اکثر ہوتا ہے، اعلیٰ ترجیحی کاموں کی وجہ سے، ان خیالات پر عمل درآمد کبھی نہیں ہو سکا۔ دریں اثنا، *ڈی ٹی کوڈ کی فیکٹرائزیشن ایکلیپس میں اب بھی پسماندہ موضوعات میں سے ایک ہے۔
ایک خاص معنوں میں، ہینڈلی پروجیکٹ کو تقریباً EMF جیسے مسائل کو حل کرنے کے لیے ڈیزائن کیا گیا ہے، لیکن ہینڈل پر مبنی ماڈلز، اور بنیادی طور پر زبان والے (یعنی، کچھ پروگرامنگ زبان کی ساخت کے عناصر کی نمائندگی کرنے والے) کے لیے۔ ہینڈلی ڈیزائن کرتے وقت جو اہم اہداف طے کیے گئے ہیں وہ ذیل میں درج ہیں:
- موضوع کے علاقے کے اہم خلاصوں کی شناخت۔
- کوشش کو کم کرنا اور کوڈ کے دوبارہ استعمال کے ذریعے ہینڈل پر مبنی لینگویج ماڈلز کے نفاذ کے معیار کو بہتر بنانا۔
- نتیجے میں آنے والے ماڈلز کو ایک متحد میٹا لیول API فراہم کرنا، عام IDE اجزاء بنانا ممکن بناتا ہے جو زبان کے ہینڈل پر مبنی ماڈلز کے ساتھ کام کرتے ہیں۔
- لچک اور توسیع پذیری۔
- Xtext کے ساتھ انضمام (ایک علیحدہ پرت میں)۔
عام تصورات اور پروٹوکول کو اجاگر کرنے کے لیے، زبان کے ہینڈل پر مبنی ماڈلز کے موجودہ نفاذ کا تجزیہ کیا گیا۔ ہینڈلی کے ذریعہ فراہم کردہ مرکزی انٹرفیس اور بنیادی نفاذات کو تصویر میں دکھایا گیا ہے۔ 8۔
چاول۔ 8. کامن انٹرفیس اور ہینڈلی عناصر کے بنیادی نفاذ
IElement انٹرفیس ایک عنصر کے ہینڈل کی نمائندگی کرتا ہے اور تمام ہینڈلی پر مبنی ماڈلز کے عناصر کے لیے عام ہے۔ خلاصہ کلاس عنصر عمومی ہینڈل/باڈی میکانزم کو نافذ کرتا ہے (تصویر 9)۔
چاول۔ 9. IElement اور عام ہینڈل/باڈی کا نفاذ
اس کے علاوہ، ہینڈلی ماڈل عناصر میں تبدیلیوں کے بارے میں مطلع کرنے کے لیے ایک عمومی طریقہ کار فراہم کرتا ہے (تصویر 10)۔ جیسا کہ آپ دیکھ سکتے ہیں، یہ وسیع پیمانے پر وسائل کے ماڈل اور جاوا ماڈل میں نافذ کردہ نوٹیفکیشن میکانزم سے ملتا جلتا ہے، اور عنصر کی تبدیلی کی معلومات کی متحد نمائندگی فراہم کرنے کے لیے IElementDelta کا استعمال کرتا ہے۔
چاول۔ 10. ہینڈلی نوٹیفکیشن میکانزم کے عمومی انٹرفیس اور بنیادی نفاذ
اوپر زیر بحث ہینڈلی حصہ (تصویر 9 اور 10) تقریباً کسی بھی ہینڈل پر مبنی ماڈل کی نمائندگی کے لیے استعمال کیا جا سکتا ہے۔ بنانے کے لیے لسانی ماڈلز، پروجیکٹ اضافی فعالیت پیش کرتا ہے - خاص طور پر، عام انٹرفیس اور سورس ٹیکسٹ ڈھانچے کے عناصر کے لیے بنیادی نفاذ، نام نہاد ماخذ عناصر (تصویر 8)۔ ISourceFile انٹرفیس سورس فائل کی نمائندگی کرتا ہے، اور ISourceConstruct سورس فائل کے اندر ایک عنصر کی نمائندگی کرتا ہے۔ خلاصہ کلاسز SourceFile اور SourceConstruct سورس فائلوں اور ان کے عناصر کے ساتھ کام کرنے میں معاونت کے لیے عمومی میکانزم کو نافذ کرتی ہیں، مثال کے طور پر، ٹیکسٹ بفرز کے ساتھ کام کرنا، سورس ٹیکسٹ میں کسی عنصر کے نقاط کا پابند ہونا، ورکنگ کاپی بفر کے موجودہ مواد کے ساتھ ماڈلز کو ہم آہنگ کرنا۔ وغیرہ ان میکانزم کو نافذ کرنا عام طور پر کافی چیلنج ہوتا ہے، اور ہینڈلی اعلی معیار کی بنیاد پر عمل درآمد فراہم کرکے ہینڈل پر مبنی لینگویج ماڈل تیار کرنے کی کوشش کو نمایاں طور پر کم کر سکتا ہے۔
اوپر درج بنیادی میکانزم کے علاوہ، ہینڈلی ٹیکسٹ بفرز اور اسنیپ شاٹس کے لیے ایک بنیادی ڈھانچہ فراہم کرتا ہے، سورس کوڈ ایڈیٹرز کے ساتھ انضمام کے لیے معاونت (بشمول Xtext ایڈیٹر کے ساتھ آؤٹ آف دی باکس انضمام)، اور ساتھ ہی کچھ عام UI اجزاء جو سورس کوڈ ایڈیٹرز کے ساتھ کام کریں۔ ہینڈلی ماڈل جیسے آؤٹ لائن فریم ورک۔ اس کی صلاحیتوں کو واضح کرنے کے لیے، پروجیکٹ کئی مثالیں فراہم کرتا ہے، بشمول ہینڈلی میں جاوا ماڈل کا نفاذ۔ (جے ڈی ٹی میں جاوا ماڈل کے مکمل نفاذ کے مقابلے میں، اس ماڈل کو زیادہ واضح کرنے کے لیے جان بوجھ کر کسی حد تک آسان بنایا گیا ہے۔)
جیسا کہ پہلے بتایا گیا ہے، ہینڈلی کے ابتدائی ڈیزائن اور اس کے بعد کی ترقی کے دوران ایک بڑی توجہ اسکیل ایبلٹی اور لچک پر تھی اور جاری ہے۔
اصولی طور پر، ہینڈل پر مبنی ماڈلز "ڈیزائن کے لحاظ سے" کافی حد تک پیمانہ ہوتے ہیں۔ مثال کے طور پر، ہینڈل/باڈی کا محاورہ آپ کو ماڈل کے ذریعے استعمال ہونے والی میموری کی مقدار کو محدود کرنے کی اجازت دیتا ہے۔ لیکن باریکیاں بھی ہیں۔ اس طرح، اسکیل ایبلٹی کے لیے Handly کی جانچ کرتے وقت، نوٹیفکیشن میکانزم کے نفاذ میں ایک مسئلہ دریافت ہوا - جب عناصر کی ایک بڑی تعداد کو تبدیل کیا گیا، ڈیلٹا کی تعمیر میں بہت زیادہ وقت لگا۔ معلوم ہوا کہ JDT جاوا ماڈل میں بھی یہی مسئلہ موجود تھا، جس سے متعلقہ کوڈ کو ایک بار ڈھال لیا گیا تھا۔ ہم نے ہینڈلی میں بگ کو ٹھیک کیا اور JDT کے لیے اسی طرح کا ایک پیچ تیار کیا، جس کا شکریہ ادا کیا گیا۔ یہ صرف ایک مثال ہے جہاں موجودہ ماڈل کے نفاذ میں Handly کو متعارف کروانا ممکنہ طور پر مفید ہو سکتا ہے، کیونکہ اس صورت میں اس طرح کے مسئلے کو صرف ایک جگہ پر ٹھیک کیا جا سکتا ہے۔
موجودہ ماڈل کے نفاذ کو تکنیکی طور پر قابل عمل بنانے کے لیے، لائبریری میں نمایاں لچک ہونی چاہیے۔ بنیادی مسئلہ پورے API ماڈل میں پسماندہ مطابقت کو برقرار رکھنا ہے۔ میں یہ مسئلہ حل ہو گیا۔ ماڈل کے لیے مخصوص API کو واضح طور پر الگ کر کے، جس کی وضاحت اور مکمل طور پر ڈویلپر کے ذریعے کنٹرول کیا جاتا ہے، لائبریری کے ذریعے فراہم کردہ متحد میٹا لیول API سے۔ یہ نہ صرف تکنیکی طور پر موجودہ نفاذ میں ہینڈلی کو لاگو کرنا ممکن بناتا ہے، بلکہ نئے ماڈل کے ڈویلپر کو API کو ڈیزائن کرتے وقت اہم آزادی بھی دیتا ہے۔
لچک کے دوسرے پہلو بھی ہیں۔ مثال کے طور پر، Handly ماڈل کے ڈھانچے پر تقریباً کوئی پابندی نہیں لگاتا اور اسے عام مقصد اور ڈومین کے لیے مخصوص زبانوں کے ماڈل بنانے کے لیے استعمال کیا جا سکتا ہے۔ سورس فائل کا ڈھانچہ بناتے وقت، Handly AST نمائندگی کی کوئی خاص شکل تجویز نہیں کرتا ہے اور اصولی طور پر، خود AST کی موجودگی کی بھی ضرورت نہیں ہے، اس طرح تقریباً کسی بھی پارسنگ میکانزم کے ساتھ مطابقت کو یقینی بناتا ہے۔ آخر میں، ہینڈلی ایکلیپس ورک اسپیس کے ساتھ مکمل انضمام کی حمایت کرتا ہے، لیکن اس کے ساتھ انضمام کی بدولت فائل سسٹم کے ساتھ براہ راست بھی کام کرسکتا ہے۔ (ای ایف ایس)۔
موجودہ ورژن دسمبر 2016 میں سامنے آیا۔ اس حقیقت کے باوجود کہ پروجیکٹ فی الحال انکیوبیشن کی حالت میں ہے اور API کو ابھی تک حتمی طور پر طے نہیں کیا گیا ہے، Handly کو پہلے سے ہی دو بڑی تجارتی مصنوعات میں استعمال کیا جاتا ہے جنہوں نے "ابتدائی اختیار کرنے والوں" کے طور پر کام کرنے کا خطرہ مول لیا، اور، مجھے یہ کہنا ضروری ہے، ابھی تک افسوس نہ کرو.
جیسا کہ اوپر بتایا گیا ہے، ان میں سے ایک پروڈکٹ 1C: انٹرپرائز ڈویلپمنٹ ٹولز ہے، جہاں ہینڈلی کا استعمال شروع سے ہی ایسے 1C کے اعلیٰ سطحی ڈھانچے کے عناصر کے ماڈل کے لیے کیا جاتا ہے: انٹرپرائز لینگویجز بلٹ ان پروگرامنگ لینگویج اور استفسار کی زبان کے طور پر۔ . ایک اور پروڈکٹ عام لوگوں کو کم معلوم ہے۔ یہ , ایپلیکیشن کے لیے مخصوص انسٹرکشن سیٹ پروسیسر (ASIP) کے لیے ایک مربوط ڈیزائن ماحول، جس کا استعمال خود چیک کمپنی Codasip کے اندر اور اس کے کلائنٹس، بشمول , , , . Codasip 2015 سے ہینڈلی کو پروڈکشن میں استعمال کر رہا ہے، ورژن Handly 0.2 سے شروع ہوتا ہے۔ Codasip Studio کی تازہ ترین ریلیز ورژن 0.5 استعمال کرتی ہے، جو جون 2016 میں ریلیز ہوئی۔ Ondřej Ilčík، جو Codasip میں IDE ڈیولپمنٹ کی قیادت کرتے ہیں، پروجیکٹ کے ساتھ رابطے میں ہیں، "تھرڈ پارٹی اپنانے والے" کی جانب سے اہم تاثرات فراہم کر رہے ہیں۔ یہاں تک کہ وہ جاوا ماڈل میں سے ایک ہینڈلی مثال کے لیے UI پرت (~ 4000 لائنز کوڈ) کو لاگو کرتے ہوئے پروجیکٹ کی ترقی میں براہ راست حصہ لینے کے لیے کچھ فارغ وقت تلاش کرنے میں کامیاب رہا۔ اپنانے والوں کے ذریعہ Handly کے استعمال کے بارے میں پہلے سے زیادہ تفصیلی معلومات صفحہ پر مل سکتی ہیں۔ پروجیکٹ
ہم امید کرتے ہیں کہ API کے استحکام کی گارنٹی کے ساتھ ورژن 1.0 کے اجراء کے بعد اور پروجیکٹ کے انکیوبیشن حالت سے نکل جانے کے بعد، Handly کے پاس نئے اختیار کرنے والے ہوں گے۔ اس دوران، پروجیکٹ API کی جانچ اور مزید بہتری کا کام جاری رکھے ہوئے ہے، ہر سال دو "بڑی" ریلیز جاری کرتا ہے - جون میں (ایک ہی وقت میں چاند گرہن کی ریلیز کے طور پر) اور دسمبر میں، ایک متوقع شیڈول فراہم کرتا ہے جس پر اختیار کرنے والے بھروسہ کر سکتے ہیں۔ ہم یہ بھی شامل کر سکتے ہیں کہ پروجیکٹ کی "بگ ریٹ" مسلسل نچلی سطح پر ہے اور Handly پہلے ورژن سے ہی ابتدائی اختیار کرنے والوں کی مصنوعات میں قابل اعتماد طریقے سے کام کر رہا ہے۔ Eclipse Handly کو مزید دریافت کرنے کے لیے، آپ استعمال کر سکتے ہیں۔ и .
ماخذ: www.habr.com